Implementação de Network Policies com Cilium e eBPF em Clusters Kubernetes

O Desafio do Tráfego Interno em Contêineres

Quando colocamos dezenas ou centenas de aplicações rodando dentro de um cluster Kubernetes (um gerenciador automatizado de contêineres), uma das maiores preocupações é garantir que um aplicativo invadido não consiga acessar os demais. Tradicionalmente, o ecossistema confia em regras de iptables, que funcionam como uma longa fila de instruções que o sistema operacional precisa ler sequencialmente para cada pacote de dados que passa pela rede. Na prática, isso significa que quanto mais regras de segurança você cria, mais lento o sistema fica, criando um gargalo invisível que drena o poder de processamento dos servidores.

Para resolver esse problema de escala e desempenho, a engenharia de redes em nuvem migrou sua atenção para o eBPF, uma tecnologia revolucionária que permite executar pequenos programas seguros diretamente dentro do núcleo do sistema operacional (o kernel), sem precisar alterar o código-fonte dele. Na prática, o eBPF age como um conjunto de sentinelas inteligentes que interceptam o tráfego de rede logo na sua chegada, aplicando filtros de segurança em velocidade de máquina e eliminando a necessidade de passar por dezenas de tabelas de roteamento convencionais.

Por Que Escolher o Cilium como CNI

O Cilium é um componente de rede (conhecido no ecossistema como CNI, ou Container Network Interface) construído desde a sua concepção para aproveitar todo o potencial do eBPF. Enquanto redes tradicionais precisam traduzir endereços IP virtuais para endereços físicos através de camadas complexas de tunelamento, o Cilium consegue rotear pacotes diretamente entre os nós do cluster com uma eficiência impressionante. Na prática, isso significa que o caminho que os dados percorrem de um aplicativo para o outro é o mais curto possível, reduzindo a latência e aumentando a estabilidade geral da infraestrutura.

Além de acelerar o tráfego, o Cilium redefine a forma como aplicamos isolamento de segurança através de políticas de rede avançadas. As regras padrão do Kubernetes limitam-se a filtrar tráfego com base em endereços IP e portas TCP, o que é insuficiente em ambientes modernos onde serviços mudam de endereço constantemente. Com o suporte nativo do Cilium, podemos criar regras baseadas na identidade dos aplicativos, como permitir que apenas o microsserviço de pagamentos converse com o banco de dados, independentemente de qual IP esses componentes estejam usando no momento.

Configurando o Ambiente e Instalando o Cilium

Antes de aplicar qualquer regra restritiva, precisamos garantir que o cluster Kubernetes esteja rodando uma versão recente do sistema operacional com suporte adequado ao kernel para o eBPF. A instalação é feita tipicamente através da ferramenta de linha de comando oficial do Cilium, chamada cilium-cli, que verifica automaticamente a compatibilidade do ambiente e aplica os componentes necessários. Na prática, você precisa ter permissões administrativas no cluster e acesso configurado ao arquivo de contexto do Kubernetes para iniciar o processo.

O procedimento padrão para implantar o Cilium em um cluster recém-criado envolve a execução de um comando direto no terminal da sua máquina de controle. Abaixo está o exemplo prático de como realizar essa instalação utilizando os parâmetros recomendados para habilitar a substituição completa do sistema de roteamento antigo:

cilium install --set ipam.mode=kubernetes --set kubeProxyReplacement=strict

Após alguns minutos, você pode verificar se todos os componentes foram iniciados corretamente executando o comando de diagnóstico integrado. Esse comando analisa a saúde dos túneis, a carga do eBPF e a conectividade entre os nós, garantindo que o plano de dados esteja pronto para receber as políticas de segurança restritivas.

cilium status --wait

Implementando Políticas de Rede Restritivas na Prática

Com o Cilium operando ativamente, podemos começar a desenhar políticas de segurança do tipo 'negação padrão' (default-deny), onde todo o tráfego é bloqueado por padrão e apenas o estritamente necessário é liberado. Essa abordagem garante que, caso um invasor obtenha acesso a um contêiner, ele permaneça isolado e sem capacidade de explorar vulnerabilidades em outros serviços vizinhos. Na prática, configuramos o sistema para exigir consentimento explícito para qualquer comunicação entre pods.

Abaixo apresentamos um manifesto YAML completo que define uma política de rede restritiva. Este exemplo bloqueia todo o tráfego de entrada para o namespace de produção, permitindo exclusivamente que pods com o rótulo específico de frontend comuniquem-se com o serviço backend na porta 8080:

apiVersion: