<h2>Network Policies em Kubernetes: Isolamento de Rede entre Pods</h2>

<p>Network Policies são recursos fundamentais do Kubernetes que permitem controlar o tráfego de rede entre pods, implementando segurança em nível de microsserviços. Por padrão, o Kubernetes permite comunicação irrestrita entre todos os pods em um cluster, o que viola o princípio do menor privilégio. Com Network Policies, você define regras explícitas de entrada (ingress) e saída (egress) de tráfego, criando um modelo de segurança robusto e granular.</p>

<p>Neste artigo, vamos explorar como as Network Policies funcionam, quando e por que utilizá-las, e como implementá-las de forma prática em seus clusters. Entender esse conceito é essencial para qualquer engenheiro que trabalha com Kubernetes em ambientes de produção.</p>

<h2>O que é uma Network Policy e Como Funciona</h2>

<h3>Entendendo o Conceito Fundamental</h3>

<p>Uma Network Policy é um objeto Kubernetes que define regras de firewall para pods. Ela atua no nível de rede, controlando quais pods podem se comunicar entre si através de seletores de labels. Quando uma Network Policy é criada, o controlador de rede do cluster (como Calico, Weave ou Cilium) implementa essas regras no sistema operacional do nó, geralmente através de iptables ou eBPF.</p>

<p>A grande diferença entre Network Policy e um firewall tradicional é que ela trabalha com abstrações do Kubernetes (labels, namespaces) ao invés de endereços IP. Isso torna as regras portáveis e dinâmicas: mesmo que um pod seja recriado com um novo IP, a política continua aplicável porque se baseia em labels.</p>

<h3>Componentes de uma Network Policy</h3>

<p>Uma Network Policy consiste em quatro elementos principais:</p>

<ul>

<li><strong>podSelector</strong>: Define quais pods a política se aplica (usando labels)</li>

<li><strong>policyTypes</strong>: Especifica se a política controla tráfego de Ingress, Egress ou ambos</li>

<li><strong>ingress</strong>: Lista de regras que permitem tráfego de entrada</li>

<li><strong>egress</strong>: Lista de regras que permitem tráfego de saída</li>

</ul>

<p>Quando uma Network Policy é aplicada a um pod através do <code>podSelector</code>, esse pod entra em modo restritivo: por padrão, todo tráfego é bloqueado, exceto o explicitamente permitido pelas regras. Isso é importante: ausência de regra significa negação.</p>

<h2>Implementando Network Policies na Prática</h2>

<h3>Exemplo 1: Bloqueio Total com Permissão Seletiva</h3>

<p>Vamos começar com um caso simples: bloquear todo o tráfego de entrada e permitir apenas de pods específicos. Este é um padrão muito comum em produção.</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: deny-all-ingress

namespace: default

spec:

podSelector: {}

policyTypes:

• Ingress</code></pre>

<p>Essa política aplica-se a <strong>todos</strong> os pods no namespace (porque <code>podSelector: {}</code> está vazio) e nega todo tráfego de entrada. Agora, vamos permitir tráfego apenas de pods com label <code>role: frontend</code>:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: allow-from-frontend

namespace: default

spec:

podSelector:

matchLabels:

role: backend

policyTypes:

• Ingress

ingress:

• from:
• podSelector:

matchLabels:

role: frontend

ports:

• protocol: TCP

port: 8080</code></pre>

<p>Aqui, apenas pods com <code>role: backend</code> são afetados. Eles receberão tráfego TCP na porta 8080 vindo de pods com <code>role: frontend</code>. Qualquer outro tráfego é bloqueado.</p>

<h3>Exemplo 2: Controle de Egress (Saída)</h3>

<p>Nem sempre pensamos em bloquear tráfego de saída, mas é igualmente importante. Vamos criar uma política que permite que um pod de aplicação acesse apenas um banco de dados específico:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: allow-app-to-db

namespace: production

spec:

podSelector:

matchLabels:

app: myapp

policyTypes:

• Egress

egress:

• to:
• podSelector:

matchLabels:

app: postgres

ports:

• protocol: TCP

port: 5432

• to:
• namespaceSelector:

matchLabels:

name: kube-system

ports:

• protocol: TCP

port: 53

• protocol: UDP

port: 53</code></pre>

<p>Neste exemplo, o pod <code>myapp</code> pode fazer requisições saintes para:</p>

<ol>

<li>Pods <code>postgres</code> na mesma rede na porta 5432</li>

<li>Qualquer pod no namespace <code>kube-system</code> nas portas 53 (DNS)</li>

</ol>

<p>Observe que adicionamos uma regra DNS. Sem ela, o pod não conseguiria resolver nomes de domínio, mesmo podendo fazer conexões.</p>

<h3>Exemplo 3: Política com Múltiplos Critérios</h3>

<p>Políticas complexas precisam de múltiplos seletores. Vamos permitir tráfego de múltiplas origens:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: complex-policy

namespace: default

spec:

podSelector:

matchLabels:

tier: api

policyTypes:

• Ingress
• Egress

ingress:

• from:
• podSelector:

matchLabels:

role: frontend

• namespaceSelector:

matchLabels:

environment: staging

ports:

• protocol: TCP

port: 8080

• from:
• namespaceSelector: {}

ports:

• protocol: TCP

port: 443

egress:

• to:
• podSelector:

matchLabels:

tier: database

ports:

• protocol: TCP

port: 5432

• to:
• namespaceSelector: {}

ports:

• protocol: TCP

port: 443

• protocol: TCP

port: 80</code></pre>

<p>Nesta política:</p>

<ul>

<li>Pods com <code>tier: api</code> recebem tráfego na porta 8080 de pods <code>frontend</code> OU de qualquer pod em namespaces com label <code>environment: staging</code></li>

<li>Recebem tráfego na porta 443 de qualquer namespace</li>

<li>Enviam tráfego apenas para pods <code>database</code> na porta 5432 e para qualquer destino nas portas 80 e 443</li>

</ul>

<h2>Estratégias e Melhores Práticas</h2>

<h3>Começar Restritivo e Evoluir</h3>

<p>A abordagem mais segura é começar com uma &quot;deny-all&quot; policy em todos os namespaces e depois adicionar permissões conforme necessário. Muitos engenheiros fazem o oposto e perdem o controle rapidamente.</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: default-deny-all

namespace: production

spec:

podSelector: {}

policyTypes:

• Ingress
• Egress</code></pre>

<p>Quando essa política está em vigor, nenhum pod consegue comunicar. A partir daí, você adiciona exceções necessárias. Essa abordagem garante que você está explicitamente permitindo o que precisa, não tentando negar tudo que não deveria.</p>

<h3>Usar Namespaces como Barreira</h3>

<p>Namespaces fornecem um isolamento organizacional natural. Combine-os com Network Policies para criar zonas de segurança:</p>

<pre><code class="language-yaml">apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: isolate-namespace

namespace: sensitive-data

spec:

podSelector: {}

policyTypes:

• Ingress
• Egress

ingress:

• from:
• namespaceSelector:

matchLabels:

name: sensitive-data

egress:

• to:
• namespaceSelector:

matchLabels:

name: sensitive-data

• to:
• podSelector:

matchLabels:

role: external-api</code></pre>

<p>Isso isola um namespace inteiro, permitindo comunicação apenas interna e com serviços externos aprovados.</p>

<h3>Debugging e Validação</h3>

<p>Para verificar se suas políticas estão funcionando, você pode testar conectividade entre pods:</p>

<pre><code class="language-bash"># Execute um pod de teste

kubectl run -it --rm debug --image=busybox --restart=Never -- sh

Dentro do pod, teste conectividade

wget -O- http://service-name:port

Verifique logs de iptables (se disponível)

kubectl exec -it pod-name -- iptables -L -n</code></pre>

<p>Uma ferramenta excelente é o <code>kube-networkpolicy-viewer</code> ou usar logs do seu CNI plugin (Calico, Cilium) para auditoria.</p>

<h2>Considerações Técnicas Importantes</h2>

<h3>Requisitos de Infraestrutura</h3>

<p>Network Policies só funcionam com CNI plugins que as suportam. Kubernetes com kubenet (padrão em alguns casos) <strong>não funciona</strong> com Network Policies. Você precisa de:</p>

<ul>

<li><strong>Calico</strong>: Excelente suporte, usa iptables/eBPF</li>

<li><strong>Cilium</strong>: Suporte avançado com eBPF, ideal para produção</li>

<li><strong>Weave</strong>: Funciona bem, bom para ambientes menores</li>

<li><strong>Kube-router</strong>: Alternativa leve</li>

</ul>

<p>Se está usando um serviço gerenciado (EKS, GKE, AKS), o provedor já oferece um CNI compatível.</p>

<h3>Performance e Impacto</h3>

<p>Network Policies baseadas em iptables podem impactar performance em clusters muito grandes com mudanças frequentes de pods. Cilium com eBPF é mais eficiente. Porém, para a maioria dos casos, o impacto é negligenciável.</p>

<p>Teste em staging antes de rollout em produção. Identifique os padrões de comunicação real:</p>

<pre><code class="language-bash"># Use ferramentas como Cilium CLI para mapear tráfego

cilium connectivity test

Ou verifique logs do seu observability stack

(Prometheus, ELK, Jaeger, etc)</code></pre>

<h2>Conclusão</h2>

<p>Network Policies são um componente essencial de uma arquitetura Kubernetes segura. Os três pontos principais que você deve levar deste artigo são:</p>

<ol>

<li><strong>Princípio do Menor Privilégio</strong>: Comece negando tudo e permita apenas o necessário. Isso previne vazamentos de dados e movimentação lateral de ataques.</li>

</ol>

<ol>

<li><strong>Abstrações Kubernetes</strong>: Use labels e seletores, não endereços IP. Isso torna suas políticas resilientes a mudanças dinâmicas de pods e fáceis de manter.</li>

</ol>

<ol>

<li><strong>Validação Contínua</strong>: Network Policies não funcionam isoladas. Combine com observability, auditoria de logs e testes regulares para garantir que estão tendo o efeito desejado.</li>

</ol>

<p>A implementação de Network Policies não é opcional em ambientes de produção, especialmente quando múltiplas equipes compartilham um cluster. Invista tempo compreendendo os padrões de comunicação reais da sua aplicação antes de implementar as políticas.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://kubernetes.io/docs/concepts/services-networking/network-policies/" target="_blank" rel="noopener noreferrer">Kubernetes Network Policies Documentation</a></li>

<li><a href="https://docs.tigera.io/calico/latest/reference/resources/networkpolicy" target="_blank" rel="noopener noreferrer">Calico Network Policy</a></li>

<li><a href="https://docs.cilium.io/en/stable/security/policy/" target="_blank" rel="noopener noreferrer">Cilium Network Policy Examples</a></li>

<li><a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf" target="_blank" rel="noopener noreferrer">Kubernetes Security Best Practices - NIST</a></li>

<li><a href="https://kubernetes.io/docs/concepts/services-networking/" target="_blank" rel="noopener noreferrer">The Kubernetes Network Model</a></li>

</ul>

<p>&lt;!-- FIM --&gt;</p>