Compreenda a segurança de rede no GKE

Este documento explica os conceitos básicos de segurança de rede do GKE, como o princípio do menor privilégio, e ajuda a escolher as ferramentas certas para proteger o seu cluster. Os principais objetivos da implementação da segurança de rede do GKE são o isolamento da carga de trabalho e a multi-posse segura. Para alcançar estes objetivos, deve aplicar os princípios do menor privilégio, da defesa em profundidade e usar dados acionáveis para fundamentar as suas decisões de segurança.

No Google Kubernetes Engine (GKE), aplicar o princípio do menor privilégio ao tráfego de rede significa restringir a comunicação apenas ao que é necessário para as suas aplicações funcionarem. Por predefinição, a rede num cluster do GKE está aberta, o que significa que todos os pods podem comunicar com todos os outros pods.

Este documento ajuda os operadores, os especialistas em redes e os especialistas em segurança a compreender e implementar a segurança de rede em clusters do GKE. Para mais informações sobre as funções comuns e exemplos de tarefas no Google Cloud, consulte o artigo Funções e tarefas comuns do utilizador do GKE.

Antes de ler este documento, verifique se conhece os seguintes aspetos:

  • Conceitos de rede do GKE: para uma vista geral, consulte o artigo Acerca das redes do GKE.
  • Pods, serviços e espaços de nomes do Kubernetes: estes recursos fundamentais do Kubernetes são essenciais para definir políticas de segurança de rede. Consulte a documentação do Kubernetes.
  • O princípio do menor privilégio: este princípio de segurança é um conceito fundamental aplicado ao longo deste documento.

Objetivos da segurança de rede do GKE

As políticas de segurança de rede do GKE oferecem um controlo de tráfego detalhado e compatível com o Kubernetes no seu cluster. Estas políticas são um elemento crítico da sua estratégia de segurança global. Para implementar uma segurança de rede robusta, considere estes princípios fundamentais:

  • Menor privilégio: conceda aos sistemas e serviços apenas os privilégios mínimos necessários para desempenharem as respetivas funções. Este princípio reduz o potencial impacto de uma violação. As políticas de rede do Kubernetes ajudam a passar de uma rede aberta por predefinição para uma em que apenas são permitidas as ligações necessárias.
  • Defesa em profundidade: aplique várias camadas de controlos de segurança independentes. Uma falha num controlo não leva a uma violação total do sistema. Por exemplo, usa uma política de rede para isolar uma base de dados, mesmo que a própria base de dados exija autenticação.
  • Dados acionáveis: baseie as decisões de segurança em dados. A modelagem de ameaças e a avaliação de riscos informam a sua postura de segurança. As funcionalidades como o registo da política de rede fornecem os dados para validar as políticas e detetar potenciais violações.

Escolha uma política de segurança de rede

Para escolher a política certa, identifique o tipo e o âmbito do tráfego que tem de controlar.

Tipos de tráfego

Para escolher a política certa, considere a origem e o destino do tráfego que quer gerir:

  • Comunicação entre pods no cluster: para controlar a forma como os microsserviços comunicam entre si, use políticas que operam em etiquetas e espaços de nomes de pods.

    • Como programador de aplicações, use o Kubernetes padrão NetworkPolicy para definir regras de entrada e saída para a sua aplicação no respetivo espaço de nomes.
    • Como administrador do cluster, use o comando CiliumClusterwideNetworkPolicy para aplicar restrições de segurança que se aplicam a todo o cluster. As regras de recusa em NetworkPolicy têm precedência sobre as regras de autorização em CiliumClusterwideNetworkPolicy.

  • Tráfego de saída de pods para serviços externos: para controlar o tráfego de saída de pods para serviços externos com base em nomes de domínios, use FQDNNetworkPolicy. Esta política é útil quando os endereços IP dos serviços externos não são estáticos, porque resolve e atualiza automaticamente os endereços IP permitidos com base no DNS.

  • Encriptação para todo o tráfego de serviço para serviço: para ajudar a garantir que toda a comunicação entre serviços é encriptada e autenticada, use uma malha de serviços. Use o Istio ou o Anthos Cloud Service Mesh para implementar o TLS mútuo (mTLS), que processa automaticamente a encriptação.

Resumo das escolhas de políticas

A tabela seguinte resume a política a usar com base no seu objetivo de segurança.

Objetivo Política recomendada
Controlar o tráfego entre pods através de etiquetas e namespaces. Kubernetes NetworkPolicy
Controlar o tráfego de saída para serviços externos por nome de domínio. FQDNNetworkPolicy
Encriptar e autenticar todo o tráfego de serviço para serviço. Istio ou Anthos Cloud Service Mesh (para mTLS)
Aplique regras obrigatórias ao nível do cluster como administrador. CiliumClusterwideNetworkPolicy
Audite e registe as ligações permitidas ou recusadas pelas políticas. Registo de políticas de rede (ativado para qualquer política)

Audite e resolva problemas de políticas de rede

Após a implementação das políticas de rede, verifique se funcionam conforme esperado e diagnostique quaisquer problemas de conetividade. Pode usar o registo da política de rede como a ferramenta principal para tal.

Quando ativa o registo da política de rede, o GKE gera um registo no Cloud Logging para cada ligação que uma política de rede permite ou recusa. Estes registos são essenciais para realizar auditorias de segurança e resolver problemas de comportamento inesperado. A revisão destes registos permite-lhe ver os efeitos concretos das suas regras, confirmando que o tráfego legítimo flui como esperado e que o tráfego não autorizado é bloqueado.

O que se segue?