Quando falamos de segurança em Kubernetes, muita gente lembra de RBAC, Secrets, ServiceAccounts, imagens seguras e scanners.

Mas existe uma camada extremamente importante que muitas vezes passa despercebida:

👉 o controle de tráfego entre Pods.

É aqui que entra a NetworkPolicy.

O que é uma NetworkPolicy? 🤔
De forma simples, uma NetworkPolicy é um recurso do Kubernetes usado para controlar políticas de entrada e saída de tráfego entre:

✅ Pods ✅ Namespaces ✅ Blocos de IP ✅ Portas específicas

Com esse recurso, conseguimos definir exatamente:

🔹 quem pode acessar um Pod 🔹 para onde um Pod pode enviar tráfego 🔹 quais portas podem ser utilizadas 🔹 quais aplicações devem ficar isoladas 🔹 quais namespaces podem se comunicar

Tudo isso é feito principalmente através de labels.

Ou seja, nós marcamos os Pods com labels e depois criamos regras dizendo quais labels podem se comunicar com outras labels.

Um ponto importante: para a NetworkPolicy funcionar, o CNI do cluster precisa dar suporte a esse recurso. Alguns exemplos são Calico, Cilium, Weave Net, entre outros.

Controlando acesso de entrada com Ingress 🚪
Imagine que temos uma aplicação sensível rodando em Pods com a label:

app: api
Agora queremos permitir que essa API seja acessada somente por Pods que tenham a label:

access: granted
A NetworkPolicy ficaria assim:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-from-granted
namespace: default
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
access: granted
Nesse exemplo, estamos dizendo:

👉 Pods com app: api só podem receber tráfego de Pods com access: granted.

Qualquer outro Pod que não tenha essa label não deve conseguir acessar essa API.

Esse tipo de política é muito útil quando temos workloads mais sensíveis, como:

🔐 bancos de dados 🔐 APIs internas 🔐 serviços administrativos 🔐 aplicações com dados financeiros 🔐 serviços de autenticação 🔐 aplicações que não devem estar disponíveis para todo o cluster

Essa é uma camada extra de segurança muito importante.

Mesmo que alguém consiga subir um Pod no cluster, isso não significa que ele conseguirá se comunicar com todos os serviços.

Controlando saída de tráfego com Egress 📤
Além de controlar quem acessa um Pod, também podemos controlar para onde um Pod pode enviar tráfego.

Esse tipo de regra é chamado de Egress.

Imagine agora que os Pods com a label:

app: api
só podem enviar tráfego para Pods com a label:

access: find-api
A NetworkPolicy ficaria assim:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-egress-to-find-api
namespace: default
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
access: find-api
Aqui estamos dizendo:

👉 Pods com app: api só podem enviar tráfego para Pods com access: find-api.

Esse tipo de controle é muito interessante quando um Pod tem um objetivo bem específico.

Por exemplo:

📌 uma API que só deve falar com um banco de dados 📌 um worker que só deve consumir mensagens de uma fila 📌 um serviço que só deve chamar uma API interna 📌 um Pod com permissões críticas que não deve acessar qualquer outro serviço 📌 uma aplicação que só deve se comunicar com um único backend

Isso ajuda bastante a reduzir o impacto caso alguma aplicação seja comprometida.

Controlando acesso por portas 🎯
Além de controlar origem e destino, também conseguimos controlar portas e protocolos.

Os protocolos mais comuns em NetworkPolicy são:

TCP
UDP
SCTP
HTTP normalmente roda sobre TCP, geralmente na porta 80.

HTTPS normalmente roda sobre TCP, geralmente na porta 443.

DNS geralmente usa UDP na porta 53, mas também pode usar TCP na porta 53 em alguns cenários.

Exemplo permitindo acesso apenas nas portas 80/TCP e 53/TCP/UDP:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-specific-ports
namespace: default
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
access: granted
ports:
- protocol: TCP
port: 80
- protocol: TCP
port: 53
- protocol: UDP
port: 53
Nesse exemplo, os Pods com app: api só podem ser acessados por Pods com access: granted, e apenas nas portas configuradas.

Isso é muito útil quando queremos garantir que uma aplicação seja acessada somente pelo caminho esperado.

Por exemplo:

🌐 uma API somente pela porta 80 🔒 uma API HTTPS somente pela porta 443 🐘 um PostgreSQL somente pela porta 5432 ⚡ um Redis somente pela porta 6379 📡 um serviço DNS somente pela porta 53

Testando se as políticas estão funcionando 🧪
Depois de criar as políticas, é importante validar se o comportamento está correto.

Podemos usar kubectl exec para entrar em um Pod e testar a comunicação.

Testando acesso HTTP 🌐
kubectl exec pod-name -n namespace -- wget -qO- http://ip-do-pod
Esse comando pode ser usado para verificar se um Pod consegue acessar outro via HTTP.

Exemplo:

kubectl exec client-pod -n default -- wget -qO- http://10.0.0.20
Aqui podemos testar se o Pod de origem com a label access: granted consegue acessar o Pod de destino com a label app: api.

Também vale testar com um Pod sem a label access: granted.

Nesse caso, o acesso deve falhar.

Testando conexão em uma porta específica 🎯
kubectl exec pod-name -n namespace -- nc -zv ip-do-pod porta
Exemplo:

kubectl exec client-pod -n default -- nc -zv 10.0.0.20 80
Esse comando testa se uma porta está acessível.

Se a política permitir tráfego na porta 80/TCP, a conexão deve funcionar.

Se você testar uma porta não permitida, a conexão deve falhar.

Testando DNS 📡
kubectl exec pod-name -n namespace -- nslookup kubernetes.default
Exemplo:

kubectl exec client-pod -n default -- nslookup kubernetes.default
Esse teste é muito importante principalmente quando criamos regras de Egress.

Quando bloqueamos toda a saída de um Pod, podemos acabar bloqueando também a resolução de DNS.

E aí acontece aquele cenário clássico:

a aplicação até tem permissão para acessar um serviço, mas não consegue resolver o nome dele.

Por isso, em políticas de Egress mais restritivas, normalmente precisamos liberar tráfego para o DNS do cluster.

Exemplo liberando DNS em Egress 📡
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-egress-dns
namespace: default
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
Com isso, os Pods com app: api conseguem consultar o DNS do cluster.

Esse tipo de regra é muito comum quando criamos políticas de saída mais restritivas.

Um ponto de atenção ⚠️
Quando aplicamos uma NetworkPolicy em um Pod, o comportamento de rede muda.

Se criamos uma política do tipo Ingress, o Pod passa a aceitar somente o tráfego de entrada permitido por aquela política.

Se criamos uma política do tipo Egress, o Pod passa a enviar somente o tráfego de saída permitido por aquela política.

Ou seja: é muito fácil bloquear mais do que deveria se a política não for bem planejada.

Por isso, antes de aplicar em produção, sempre vale testar em um ambiente controlado.

Conclusão 🚀
NetworkPolicy é um recurso muito poderoso para aumentar a segurança dentro de um cluster Kubernetes.

Com ela, conseguimos sair daquele modelo onde:

“todo mundo fala com todo mundo”
E passar para um modelo mais controlado, onde:

“cada aplicação só se comunica com o que realmente precisa”
Isso ajuda em vários cenários:

✅ isolamento de banco de dados ✅ proteção de APIs internas ✅ controle de tráfego entre namespaces ✅ redução do impacto em caso de invasão ✅ aplicação do princípio do menor privilégio ✅ maior previsibilidade na comunicação entre serviços

No fim, NetworkPolicy não é só sobre bloquear tráfego.

É sobre desenhar melhor a comunicação entre as aplicações.

E em Kubernetes, isso faz muita diferença. 🔐☸️