Segurança de containers e Kubernetes: checklist com 25 itens

Containers e Kubernetes mudaram a forma como aplicações são empacotadas e operadas, e trouxeram uma superfície de ataque própria: imagens com centenas de pacotes que ninguém escolheu, manifestos YAML com permissões generosas e um plano de controle que, se comprometido, entrega tudo.

Este checklist está organizado na ordem em que o container vive: construção da imagem, armazenamento, configuração no cluster e operação.

Imagem

1. Use uma imagem base mínima. Distroless, Alpine, Wolfi ou variantes slim reduzem drasticamente o número de pacotes e de CVEs. Trocar a imagem base costuma eliminar mais de 90% das vulnerabilidades de uma vez. Imagens endurecidas levam isso ao limite.
2. Fixe a imagem base por digest, não por tag. Tags podem ser movidas.
3. Use build em múltiplos estágios. Compiladores, gerenciadores de pacotes e ferramentas de build ficam no estágio de build, fora da imagem final.
4. Rode como usuário sem privilégios. Declare USER com um UID diferente de zero no Dockerfile.
5. Nunca copie secrets para a imagem. Nem .env, nem chaves, nem tokens de registry privado. Use secrets de build, que não ficam nas camadas.
6. Mantenha um .dockerignore para não levar .git, arquivos locais e credenciais para o contexto de build.

FROM node:22-slim@sha256:<digest> AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts
COPY . .
RUN npm run build && npm prune --omit=dev

FROM gcr.io/distroless/nodejs22-debian12@sha256:<digest>
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER 10001
CMD ["dist/server.js"]

Build e registry

7. Analise a imagem no CI, antes do push, com política que falha o build em vulnerabilidades críticas com correção disponível. Veja varredura de imagens de container.
8. Continue analisando depois do push. CVEs novas aparecem para imagens antigas. O registry precisa de varredura contínua.
9. Assine as imagens e verifique a assinatura no deploy.
10. Gere SBOM de cada imagem e anexe como atestado. Veja o guia de SBOM.
11. Restrinja quem pode fazer push no registry. Pipelines, não pessoas.

Configuração do pod

12. runAsNonRoot: true e um runAsUser explícito.
13. allowPrivilegeEscalation: false.
14. Remova todas as capabilities e adicione só as necessárias.
15. readOnlyRootFilesystem: true, com volumes temporários onde a aplicação precisa escrever.
16. Sem privileged, hostNetwork, hostPID ou hostPath sem justificativa documentada.
17. Defina requests e limits de CPU e memória, para que um pod comprometido não derrube o nó.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

18. Aplique os Pod Security Standards no nível restricted por namespace, com o admission controller nativo.

Identidade e RBAC

19. Desative o automount do token da service account nos pods que não falam com a API do Kubernetes.
20. Nada de cluster-admin para aplicações. Roles com verbos e recursos específicos, por namespace.
21. Use identidade de workload (IRSA na AWS, Workload Identity no GKE e no AKS) em vez de chaves de nuvem montadas como secret.

Rede

22. Network policy padrão de negação em cada namespace, liberando só o tráfego necessário.
23. Plano de controle privado ou restrito por IP, com autenticação integrada ao provedor de identidade.

Segredos

24. Secrets do Kubernetes não são criptografados por padrão, apenas codificados em base64. Ative a criptografia em repouso no etcd ou use um gerenciador externo com sincronização, e nunca coloque secrets em ConfigMaps.

Operação

25. Monitore em runtime. Varredura estática não vê um processo inesperado rodando dentro do container. A proteção em runtime bloqueia injeção e SSRF na aplicação, e a avaliação contínua do cluster detecta mudanças fora do pipeline.

Priorize pelo que está exposto

Um cluster médio tem dezenas de imagens com centenas de CVEs. Comece pelas imagens que:

1. Estão rodando (imagens no registry que não rodam em lugar nenhum descem na fila)
2. Estão expostas por Ingress ou LoadBalancer
3. Têm permissões na nuvem que alcançam dados sensíveis

Essa combinação forma um caminho de ataque, e cortar o caminho no ponto certo vale mais que corrigir cem CVEs isoladas. A avaliação de clusters Kubernetes da TransiTax Security cruza exatamente esses sinais.