Containers em produção: como usar Docker e Kubernetes com segurança operacional

O que vai errado com containers em produção

A adoção de containers frequentemente acontece mais rápido do que a maturidade operacional para gerenciá-los. Os problemas mais comuns: imagens rodando como root, secrets em variáveis de ambiente em texto puro, imagens base desatualizadas com vulnerabilidades conhecidas e limites de recursos não definidos (um container pode consumir todo o CPU do node).

As práticas de segurança que não são opcionais

• Non-root user — containers devem rodar com usuário não-privilegiado. Violação é risco crítico de segurança.
• Imagens mínimas — use imagens distroless ou Alpine ao invés de Ubuntu completo. Menos surface de ataque e menor tamanho.
• Read-only filesystem — containers que não precisam escrever no sistema de arquivos devem ter o filesystem read-only.
• Secrets via mounted volumes ou Secrets Manager — nunca em variáveis de ambiente que aparecem em logs.
• Resource limits — todo container deve ter CPU e memory limits definidos para prevenir noisy neighbor.

O ciclo de vida de uma imagem segura

Build com imagem base mínima → scan de vulnerabilidades (Trivy, Grype) antes do push → push para registry privado com assinatura → deploy com admission controller que rejeita imagens não assinadas → scan periódico de imagens em execução para vulnerabilidades novas.