Segurança de contentores.

A segurança de contentores cobre todo o ciclo de vida dos contentores OCI (Docker, containerd, CRI-O). No build, as equipas analisam imagens à procura de CVEs e segredos, assinam-nas com Sigstore/Cosign e impõem imagens base mínimas. Na distribuição, os registos são protegidos com acessos autenticados e verificação de assinaturas. Em runtime, hardening do host, isolamento por namespaces/cgroups, seccomp, AppArmor e sistemas de ficheiros só de leitura reduzem a superfície de ataque, enquanto admission controllers e sensores baseados em eBPF aplicam políticas e detetam anomalias.

Os contentores partilham o kernel do host, pelo que uma única falha do kernel ou do runtime pode quebrar o isolamento. A CVE-2019-5736 permitia que uma imagem maliciosa sobrescrevesse o binário runc do host através de /proc/self/exe, obtendo execução de código como root no nó; foi corrigida no runc 1.0-rc7 e no Docker 18.09.2. Em 2024, a "Leaky Vessels" CVE-2024-21626 expunha um descritor de ficheiro interno (fd/7) que apontava para o diretório de trabalho do host antes do pivot_root, de modo que definir o cwd do contentor como /proc/self/fd/7 permitia escapar do rootfs (corrigida no runc 1.1.12). Como a fuga de um pod costuma equivaler ao comprometimento do nó, a defesa em profundidade é crucial: remover capabilities, executar como não-root, evitar montagens privilegiadas e hostPath, manter o runc atualizado e considerar sandboxes mais fortes como gVisor ou Kata Containers.

flowchart LR
  A[Build: analisar + assinar imagem] --> B[Registo: autenticar + verificar assinatura]
  B --> C[Admissao: rejeitar privilegiado/hostPath]
  C --> D[Runtime: seccomp, AppArmor, nao-root, caps removidas]
  D --> E[Detecao: alertas eBPF/Falco]
  D -. falha kernel/runc .-> X[Fuga do contentor para o host]
  X -. mitigada por .-> F[Sandbox gVisor / Kata]