Cilium e eBPF: Rede e Segurança no Kubernetes para PME

1. Introdução

Gerir a rede de um cluster Kubernetes numa pequena ou média empresa (PME) traz desafios concretos: garantir isolamento entre serviços, aplicar políticas de segurança granulares e manter visibilidade sobre o tráfego. O Cilium resolve estes problemas usando eBPF (extended Berkeley Packet Filter) para substituir o modelo tradicional baseado em iptables, oferecendo políticas de rede ao nível 7 (L7) e observabilidade integrada através do Hubble.

Para uma PME que usa K3s ou Kubernetes autogerido, o Cilium elimina a complexidade das cadeias de regras iptables que crescem linearmente com o número de pods. Em vez de centenas de regras processadas sequencialmente, o eBPF executa programas compilados directamente no kernel Linux, com desempenho quase constante independentemente do tamanho do cluster.

2. O que é eBPF

O eBPF é uma tecnologia do kernel Linux que permite executar programas isolados em ambientes privilegiados sem need de carregar módulos de kernel ou reiniciar o sistema. Originalmente concebido para filtragem de pacotes (BPF clássico), o eBPF evoluiu para uma plataforma geral de programação do kernel, usada em redes, segurança, observabilidade e desempenho.

No contexto do Kubernetes, o eBPF permite que o Cilium intercepte e processe pacotes de rede em pontos estratégicos do kernel — como tc (traffic control), cgroup e socket — sem modificar o código do kernel. Os programas eBPF são compilados em bytecode, verificados pelo kernel quando carregados (verifier) e executados em JIT (Just-In-Time compilation) para eficiência nativa.

2.1 Vantagens do eBPF para redes Kubernetes

O modelo tradicional baseia-se em iptables, que processa regras sequencialmente. Num cluster com 1000 pods, cada pacote pode atravessar centenas de regras. O eBPF substitui este modelo por mapas hash (lookup tables) no kernel, onde a pesquisa é O(1) — o tempo de processamento não depende do número de regras.

3. Instalar Cilium no K3s/K8s

O K3s é uma distribuição Kubernetes leve, ideal para PME. Por defeito, o K3s usa o Flannel como CNI. Para substituir o Flannel pelo Cilium, é necessário desactivar o CNI integrado do K3s e instalar o Cilium com a CLI oficial ou via Helm.

3.1 Passo 1 — Instalar K3s sem CNI nativo

Ao instalar o K3s, use a flag --flannel-backend=none para desactivar o Flannel e permitir que o Cilium assuma o papel de CNI:

# Instalar K3s sem Flannel
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--flannel-backend=none --disable-network-policy" sh -

# Verificar que o K3s está a correr
kubectl get nodes

# Exportar kubeconfig
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

3.2 Passo 2 — Instalar a CLI do Cilium

A CLI do Cilium simplifica a instalação com detecção automática da melhor configuração para a distribuição Kubernetes em uso:

# Instalar a CLI do Cilium (Linux)
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CILIUM_CLI_VERSION}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CILIUM_CLI_VERSION}.tar.gz.sha256sum
sudo tar xzf cilium-linux-${CILIUM_CLI_VERSION}.tar.gz -C /usr/local/bin
rm cilium-linux-${CILIUM_CLI_VERSION}.tar.gz*

# Verificar instalação
cilium version

3.3 Passo 3 — Instalar Cilium no cluster

Com a CLI instalada, executar cilium install detecta automaticamente o ambiente e aplica a configuração ideal. Para K3s, o Cilium usa o modo de encapsulamento adequado (VXLAN ou routing directo):

# Instalar Cilium com configuração automática
cilium install

# Validar a instalação
cilium status --wait

# Verificar conectividade entre pods
cilium connectivity test

3.4 Instalação via Helm (alternativa)

Para PME que preferem Gestão como Código (GitOps), o Helm oferece controlo declarativo sobre a configuração:

# Adicionar repositório Helm do Cilium
helm repo add cilium https://helm.cilium.io/
helm repo update

# Instalar Cilium com Helm
helm install cilium cilium/cilium --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

4. Network Policies L7

As Network Policies nativas do Kubernetes operam apenas ao nível 3/4 (IP e porta). O Cilium estende este modelo para o nível 7, permitindo filtrar tráfego HTTP, gRPC, Kafka e DNS. Para uma PME, isto significa poder restringir que um serviço de frontend só pode chamar GET /api/users na API de backend, e bloquear DELETE /api/users.

4.1 Política L3/L4 — isolamento básico

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: producao
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

4.2 Política L7 — filtragem HTTP

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-http-l7
  namespace: producao
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/users.*"

Neste exemplo, o frontend só pode fazer GET /api/users no backend. Qualquer outro método HTTP ou caminho é bloqueado pelo eBPF no kernel, sem overhead de proxy sidecar.

5. Hubble — Observabilidade

O Hubble é a camada de observabilidade do Cilium. Fornece visibilidade em tempo real sobre fluxos de rede ao nível de serviço, protocolo e política aplicada. Para uma PME sem equipa de operations dedicada, o Hubble oferece uma ferramenta pronta a usar para diagnóstico de conectividade e auditoria de segurança.

5.1 Activar Hubble

Se instalou o Cilium via Helm com hubble.enabled=true, o Hubble já está activo. Para activar via CLI:

# Activar Hubble Relay e UI
cilium hubble enable --ui

# Verificar estado do Hubble
cilium hubble status

# Port-forward para aceder à UI
cilium hubble ui

5.2 Inspeccionar fluxos de rede com a CLI

# Ver fluxos em tempo real
hubble watch

# Filtrar tráfego negado (denied)
hubble watch --verdict DENIED

# Ver service map (mapa de serviços)
hubble observe --type trace

# Exportar métricas para Prometheus
# O Hubble expõe métricas em /metrics na porta 9965

O Hubble distingue-se de outras ferramentas de observabilidade porque extrai dados directamente do eBPF — não precisa de sidecars, agents adicionais ou packet captures. Cada fluxo inclui identidade (labels do pod), protocolo (HTTP, gRPC, Kafka), veredito (allowed/denied) e a política que foi aplicada.

6. Comparação Cilium vs iptables

A tabela seguinte resume as diferenças fundamentais entre o modelo tradicional baseado em iptables e o Cilium com eBPF para PME que avaliam a migração:

7. Boas Práticas

Para uma PME que adopta Cilium em produção, estas práticas garantem estabilidade, segurança e manutenibilidade do cluster:

7.1 Começar com default-deny

Aplique uma política default-deny em cada namespace antes de adicionar políticas específicas. Isto garante que apenas tráfego explicitamente permitido passa, seguindo o princípio do menor privilégio:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: default-deny
  namespace: producao
spec:
  description: "Bloquear todo o tráfego por defeito"
  endpointSelector: {}

7.2 Usar identidades em vez de IPs

O Cilium atribui identidade (security identity) a cada pod com base nos labels. Use sempre fromEndpoints e toEndpoints com labels em vez de CIDRs IP. IPs de pods são efémeros — mudam em cada reinício ou scaling event.

7.3 Monitorizar com Hubble em produção

Mantenha o Hubble activo e configure alertas para tráfego DENIED. Fluxos negados indicam ou tentativas de acesso indevido (potencial incidente de segurança) ou configuração incorrecta de políticas (aplicação que não funciona por falta de permissão).

7.4 Versionar políticas em Git

Guarde todas as CiliumNetworkPolicy como ficheiros YAML num repositório Git e aplique via kubectl apply -k ou Flux/ArgoCD. Isto garante auditoria, rollback e revisão por pares (pull requests) — essencial para compliance em PME.

7.5 Manter kernel actualizado

O eBPF evolui com cada versão do kernel Linux. Mantenha os nós do cluster em kernel 5.10+ (idealmente 5.15+ ou 6.x) para tirar partido das funcionalidades mais recentes do eBPF, incluindo melhor verifier, novos hooks de rede e melhor desempenho.