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

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 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 executar 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 o registro 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 padrão Kubernetes NetworkPolicy para definir regras de entrada e saída do aplicativo no namespace.
    • Como administrador de cluster, use o CiliumClusterwideNetworkPolicy para aplicar barreiras de proteção de segurança que se aplicam a todo o cluster. As regras de negação em NetworkPolicy têm precedência sobre as CiliumClusterwideNetworkPolicy regras de permissão.

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

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 regras obrigatórias em todo o cluster como administrador. CiliumClusterwideNetworkPolicy
Auditar e registrar conexões permitidas ou negadas por políticas. Registro de políticas de rede (ativado 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 registro de políticas de rede como a principal ferramenta para isso.

Quando você ativa o registro 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.

A seguir