Entender a segurança de rede no GKE

Este documento explica os principais conceitos de segurança de rede do GKE, como o princípio de privilégio mínimo, e ajuda você a escolher as ferramentas certas para proteger seu cluster. Os principais objetivos da implementação da segurança de rede do GKE são o isolamento de cargas de trabalho e a multilocação segura. Para alcançar essas metas, aplique os princípios de privilégio mínimo e defesa em profundidade e use dados úteis para fundamentar suas decisões de segurança.

No Google Kubernetes Engine (GKE), aplicar o princípio de privilégio mínimo ao tráfego de rede significa restringir a comunicação apenas ao que é necessário para o funcionamento dos aplicativos. Por padrão, a rede em um cluster do GKE é aberta, o que significa que todos os pods podem se comunicar entre si.

Este documento ajuda operadores, especialistas em rede e especialistas em segurança a entender e implementar a segurança de rede em clusters do GKE. Para mais informações sobre papéis comuns e tarefas de exemplo no Google Cloud, consulte Funções e tarefas de usuário comuns do GKE.

Antes de ler este documento, verifique se você conhece os seguintes tópicos:

  • Conceitos de rede do GKE: para uma visão geral, consulte Sobre a rede do GKE.
  • Pods, serviços e namespaces do Kubernetes: esses 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 de privilégio mínimo: esse princípio de segurança é um conceito fundamental aplicado em todo este documento.

Metas da segurança de rede do GKE

As políticas de segurança de rede do GKE oferecem controle de tráfego granular e compatível com o Kubernetes no cluster. Elas são um elemento essencial da sua estratégia geral de segurança. Para implementar uma segurança de rede robusta, considere estes princípios fundamentais:

  • Privilégio mínimo: conceda aos sistemas e serviços apenas os privilégios mínimos necessários para realizar as funções. Esse princípio reduz o possível impacto de uma violação. As políticas de rede do Kubernetes ajudam você a migrar de uma rede aberta por padrão para uma em que apenas as conexões necessárias são permitidas.
  • Defesa em profundidade: camadas de vários controles de segurança independentes. Uma falha em um controle não leva a um comprometimento total do sistema. Por exemplo, você usa uma política de rede para isolar um banco de dados, mesmo que ele 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 sua postura de segurança. Recursos como geração de registros de políticas de rede fornecem os dados para verificar políticas e detectar possíveis violações.

Escolher uma política de segurança de rede

Para escolher a política certa, identifique o tipo e o escopo do tráfego que você precisa controlar.

Tipos de tráfego

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

  • Comunicação entre pods no cluster: para controlar como os microsserviços se comunicam entre si, use políticas que operam em rótulos e namespaces de pods.

    • Como desenvolvedor de aplicativos, use o NetworkPolicy padrão do Kubernetes para definir regras de entrada e saída do aplicativo no namespace dele.
    • Como administrador do cluster, use o CiliumClusterwideNetworkPolicy para aplicar políticas de segurança que se aplicam a todo o cluster. As regras de negação em NetworkPolicy têm precedência sobre as regras de permissão 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ínio, use FQDNNetworkPolicy. Essa política é útil quando os endereços IP de serviços externos não são estáticos, porque ela resolve e atualiza automaticamente os endereços IP permitidos com base no DNS.

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

Resumo das opções de política

A tabela a seguir resume qual política usar com base na sua meta de segurança.

Meta Política recomendada
Controlar o tráfego entre pods usando rótulos e namespaces. Kubernetes NetworkPolicy
Controlar o tráfego de saída para serviços externos por nome de domínio. FQDNNetworkPolicy
Criptografar e autenticar todo o tráfego entre serviços. Istio ou Anthos Cloud Service Mesh (para mTLS)
Imponha regras obrigatórias em todo o cluster como administrador. CiliumClusterwideNetworkPolicy
Auditar e registrar conexões permitidas ou negadas por políticas. Geração de registros de política de rede (ativada para qualquer política)

Auditar e resolver problemas de políticas de rede

Depois de implementar as políticas de rede, verifique se elas funcionam conforme o esperado e diagnostique problemas de conectividade. Use o registro de políticas de rede como a principal ferramenta para isso.

Quando você ativa a geração de registros de política de rede, o GKE gera um registro de registro no Cloud Logging para cada conexão permitida ou negada por uma política de rede. Esses registros são essenciais para realizar auditorias de segurança e resolver problemas de comportamento inesperado. Ao analisar esses registros, você pode conferir os efeitos concretos das suas regras, confirmando que o tráfego legítimo flui conforme o esperado e que o tráfego não autorizado é bloqueado.

A seguir