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 da carga de trabalho e a multilocação segura. Para atingir esses objetivos, aplique os princípios de privilégio mínimo e defesa em profundidade e use dados acionáveis para informar 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 que os aplicativos funcionem. Por padrão, a rede em um cluster do GKE é aberta, o que significa que cada pod pode se comunicar com todos os outros.

O GKE agora oferece suporte a uma abordagem hierárquica para segurança de rede usando ClusterNetworkPolicy para aplicação no nível administrativo em todos os namespaces.

Este documento fornece informações que operadores, especialistas em rede e especialistas em segurança precisam entender e implementar a segurança de rede em clusters do GKE. Para mais informações sobre funções comuns e tarefas de exemplo em Google Cloud, consulte Funções e tarefas comuns do usuário do GKE.

Antes de ler este documento, verifique se você está familiarizado com o seguinte:

  • 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.

Objetivos da segurança de rede do GKE

As políticas de segurança de rede do GKE fornecem controle de tráfego refinado e compatível com o Kubernetes no cluster. Essas políticas são um elemento essencial da sua estratégia de segurança geral. 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 impacto potencial de uma violação. As políticas de rede do Kubernetes ajudam você a passar 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 uma violação 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: decisões de segurança baseadas em dados. A modelagem de ameaças e a avaliação de riscos informam sua postura de segurança. Recursos como a 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 a NetworkPolicy padrão do Kubernetes NetworkPolicy para definir regras de entrada e saída do aplicativo no namespace.
    • Como administrador de cluster, use a ClusterNetworkPolicy padrão do Kubernetes para aplicar proteções de segurança obrigatórias (nível Admin) ou estabelecer padrões de confiança zero (nível Baseline) em todos os namespaces. Esse recurso é compatível com clusters que executam a versão 1.36.1-gke.1067000 ou mais recente do GKE.
    • Como administrador de cluster, use a CiliumClusterwideNetworkPolicy proprietária para controle de tráfego especializado em todo o cluster. Para novas implantações, use a ClusterNetworkPolicy nativa do Kubernetes em vez dessa política reservada.

  • 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 de serviço para serviço: para garantir que toda a comunicação entre serviços seja criptografada e autenticada, use um service mesh. Use Istio ou o Anthos Cloud Service Mesh para implementar o TLS mútuo (mTLS), que processa a criptografia automaticamente.

Níveis de avaliação de políticas

O GKE avalia as políticas de segurança de rede em três níveis hierárquicos.

  1. Nível de administrador (ClusterNetworkPolicy): o nível mais alto de precedência. Use esse nível para aplicar mandatos de segurança obrigatórios. As regras de negação nesse nível substituem todas as outras políticas. As regras de aceitação permitem o tráfego e interrompem a avaliação desse pacote.
  2. Nível NetworkPolicy: o nível em que os desenvolvedores definem a segurança específica do aplicativo. As políticas incluem os recursos padrão NetworkPolicy, FQDNNetworkPolicy, e CiliumClusterwideNetworkPolicy.
  3. Nível de referência (ClusterNetworkPolicy): o nível mais baixo de precedência. Use esse nível para definir proteções padrão de "negação por padrão" que os desenvolvedores podem substituir seletivamente no nível NetworkPolicy.

Se nenhuma política corresponder em qualquer nível, o GKE usará um comportamento implícito de "permitir tudo".

Resumo das opções de política

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

Objetivo 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 de serviço para serviço. Istio ou Anthos Cloud Service Mesh (para mTLS)
Aplicar proteções de segurança obrigatórias e não substituíveis. ClusterNetworkPolicy (nível de administrador)
Estabelecer proteções padrão de "confiança zero" que os desenvolvedores podem substituir. ClusterNetworkPolicy (nível de referência)
Configurar políticas proprietárias em todo o cluster (não recomendado para novas implantações). CiliumClusterwideNetworkPolicy
Auditar e registrar conexões permitidas ou negadas por políticas. Geração de registros de políticas de rede (ativada para qualquer política)

Auditar e solucionar problemas de políticas de rede

Depois de implementar políticas de rede, verifique se elas funcionam conforme o esperado e diagnostique problemas de conectividade. Você pode usar a geração de registros de políticas de rede como a principal ferramenta para isso.

Quando você ativa a geração de registros de políticas de rede, o GKE gera um registro de log no Cloud Logging para cada conexão que uma política de rede permite ou nega. Esses registros são essenciais para realizar auditoria de segurança e solucionar problemas de comportamento inesperado. A revisão desses registros permite que você veja os efeitos concretos das regras, confirmando que o tráfego legítimo flui conforme o esperado e que o tráfego não autorizado é bloqueado.

Ao contrário das políticas padrão, que são "somente permissão", os recursos ClusterNetworkPolicy oferecem suporte a ações negar explícitas. Se uma política administrativa descartar o tráfego, o registro de log atribuirá a negação à política específica responsável pelo bloqueio.

A seguir