Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Sidecars for endpoint security

Last updated : Nov 20, 2019
NOT ON THE CURRENT EDITION
This blip is not on the current edition of the Radar. If it was on one of the last few editions, it is likely that it is still relevant. If the blip is older, it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the Radar. Understand more
Nov 2019
Trial ?

Many of the technical solutions we build today run in increasingly complex polycloud or hybrid-cloud environments with multiple distributed components and services. Under such circumstances, we apply two security principles early in implementation: zero trust network, never trust the network and always verify; and the principle of least privilege, granting the minimum permissions necessary for performing a particular job. Sidecars for endpoint security is a common technique we use to implement these principles to enforce security controls at every component's endpoint, e.g., APIs of services, data stores or Kubernetes control interface. We do this using an out-of-process sidecar — a process or a container that is deployed and scheduled with each service sharing the same execution context, host and identity. Open Policy Agent and Envoy are tools that implement this technique. Sidecars for endpoint security minimize the trusted footprint to a local endpoint rather than the network perimeter. We like to see the responsibility of sidecar’s security policy configuration left with the team that is responsible for the endpoint and not a separate centralized team.

May 2018
Assess ?

Microservices architecture, with a large number of services exposing their assets and capabilities through APIs and an increased attack surface, demand a zero trust security architecture — ‘never trust, always verify’. However, enforcing security controls for communication between services is often neglected, due to increased service code complexity and lack of libraries and language support in a polyglot environment. To get around this complexity, some teams delegate security to an out-of-process sidecar — a process or a container that is deployed and scheduled with each service sharing the same execution context, host and identity. Sidecars implement security capabilities, such as transparent encryption of the communication and TLS (Transport Layer Security) termination, as well as authentication and authorization of the calling service or the end user. We recommend you look into using Istio, linkerd or Envoy before implementing your own sidecars for endpoint security.

Nov 2017
Assess ?

Microservices architecture, with a large number of services exposing their assets and capabilities through APIs and an increased attack surface, demand a zero trust security architecture — ‘never trust, always verify’. However, enforcing security controls for communication between services is often neglected, due to increased service code complexity and lack of libraries and language support in a polyglot environment. To get around this complexity, some teams delegate security to an out-of-process sidecar — a process or a container that is deployed and scheduled with each service sharing the same execution context, host and identity. Sidecars implement security capabilities, such as transparent encryption of the communication and TLS (Transport Layer Security) termination, as well as authentication and authorization of the calling service or the end user. We recommend you look into using Istio, linkerd or Envoy before implementing your own sidecars for endpoint security.

Published : Nov 30, 2017

Download the PDF

 

 

 

English | Español | Português | 中文

Sign up for the Technology Radar newsletter

 

Subscribe now

Visit our archive to read previous volumes