Network Policies no Kubernetes: segmentação de rede como controle de segurança

O problema padrão do Kubernetes

Uma das configurações padrão mais perigosas do Kubernetes é a ausência de restrições de rede entre Pods. Por default, qualquer Pod pode fazer requisições para qualquer outro Pod no cluster — independente de namespace, label ou aplicação. Em termos práticos: se um container for comprometido, o atacante tem acesso de rede a todos os outros serviços do cluster, incluindo bancos de dados, serviços internos e APIs privilegiadas.

Network Policies são o mecanismo nativo do Kubernetes para definir quais Pods podem se comunicar com quais — e devem ser parte de qualquer ambiente de produção com requisitos mínimos de segurança.

Como Network Policies funcionam

Uma Network Policy é um recurso Kubernetes que seleciona Pods via podSelector e define regras de ingress (tráfego entrante) e egress (tráfego sainte) permitidos. Políticas são aditivas: se nenhuma política seleciona um Pod, todo tráfego é permitido. Se pelo menos uma política seleciona um Pod, apenas o tráfego explicitamente permitido é aceito.

O baseline correto: deny-all primeiro

A abordagem recomendada é começar com uma política de deny-all por namespace e então abrir explicitamente apenas o tráfego necessário:

• Deny all ingress — bloqueia todo tráfego entrante para Pods do namespace por padrão.
• Deny all egress — bloqueia todo tráfego sainte, forçando que cada serviço declare explicitamente com quem precisa se comunicar.
• Allow por label — abre tráfego entre serviços específicos via podSelector com labels semânticos (app: api pode falar com app: database).
• Allow DNS — egress para o kube-dns (porta 53 UDP/TCP) precisa ser explicitamente liberado — sem isso, a resolução de nomes falha.

Ferramentas que ampliam as capacidades nativas

• Calico — implementa Network Policies nativas e adiciona GlobalNetworkPolicy (aplicável a todo o cluster) e políticas baseadas em CIDR externo. Amplamente adotado em ambientes on-premise e cloud.
• Cilium — usa eBPF para aplicar políticas no kernel, com suporte a políticas de camada 7 (HTTP, DNS, Kafka) — não apenas IP/porta. Permite regras como "o serviço A pode fazer GET em /api/v1/users mas não POST".

Como verificar que as políticas estão funcionando

Network Policies silenciosas que não funcionam por falta de CNI compatível são um risco real. Para verificar: use kubectl exec para testar conectividade entre Pods que deveriam estar bloqueados, use ferramentas como netassert ou kubesec para validação automatizada, e inclua testes de conectividade negativa como parte do pipeline de CI.