Muitas das soluções técnicas que construímos hoje rodam em ambientes cada vez mais complexos de polycloud ou nuvem híbrida com múltiplos componentes e serviços distribuídos. Sob essas circunstâncias, usamos dois princípios de segurança no começo de uma implementação: rede com zero confiança, ou seja, nunca confie na rede e sempre verifique; e o princípio do mínimo privilégio, dando o mínimo de permissões necessárias para realizar um trabalho em particular. Os sidecars para segurança de terminal são uma técnica comum que usamos para implementar esses princípios para aplicar controles de segurança em cada terminal de componente (ex.: APIs de serviços, armazéns de dados ou interface de controle Kubernetes). Fazemos isso usando um sidecar fora do processo – um processo ou um contêiner que é implantado ou agendado com cada serviço, compartilhando o mesmo contexto de execução, hospedagem e identidade. Open Policy Agent e Envoy são ferramentas que implementam essa técnica. Sidecars para segurança de terminal minimizam a área de cobertura confiável para um terminal local, em vez do perímetro de rede. Gostamos de ver a responsabilidade da configuração da política de segurança do sidecar com o time que é responsável pelo terminal e não um time centralizado separado.
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.
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.
