Habilidade de Endurecimento de Segurança de Contêineres

Um guia focado em produção para construir, escanear e executar contêineres de forma segura — desde a autoria do Dockerfile até a aplicação em tempo de execução e a integridade da cadeia de suprimentos.

Guia Detalhado

Leia o guia detalhado antes de executar esta habilidade. Ele contém o procedimento completo e o material de referência. Trate seus requisitos de segurança, pré-requisitos e validação como obrigatórios. Para trabalho focado, carregue as seções relevantes; para trabalho de ponta a ponta, leia o guia completamente.

Quando Usar Esta Habilidade

• O usuário menciona segurança do Docker, endurecimento de contêineres ou revisão de segurança do Dockerfile
• O usuário pergunta sobre imagens distroless, contêineres não root ou sistemas de arquivos somente leitura
• O usuário quer escanear imagens para CVEs com Trivy, Grype ou Snyk
• O usuário menciona seccomp, AppArmor, capacidades do Linux ou segurança em tempo de execução
• O usuário pergunta "meu Dockerfile é seguro?" ou "como reduzo a superfície de ataque da minha imagem?"
• O usuário quer assinar/verificar imagens com Cosign ou gerar SBOMs
• O usuário pergunta sobre segurança de pods do Kubernetes, NetworkPolicy ou endurecimento de RBAC
• O usuário diz "corrigir CVEs de contêineres" ou "endurecer meu contêiner para produção"

Quando NÃO Usar Esta Habilidade

• O usuário está perguntando principalmente sobre CI/CD do GitHub Actions → recomende github-actions-advanced
• O usuário precisa de ajuda geral com o uso do Docker (não segurança) → recomende docker-expert
• O usuário está trabalhando com orquestração do Kubernetes além da segurança → recomende kubernetes-architect
• O usuário precisa de segurança em nível de aplicativo (injeção de SQL, XSS) → recomende api-security-best-practices

Checklist de Segurança

Dockerfile

• Imagem base mínima (distroless, slim ou alpine — não debian/ubuntu completo)
• Build multi-estágio — sem ferramentas de build, devDependencies ou compiladores na imagem de runtime
• Usuário não root USER declarado antes de CMD/ENTRYPOINT
• Imagem base fixada no digest @sha256:... (não apenas tag)
• Sem segredos nos comandos ENV, ARG ou RUN
• HEALTHCHECK definido
• Rótulos OCI presentes (org.opencontainers.image.*)
• .dockerignore exclui .git, .env, segredos, testes
• ENTRYPOINT usa forma exec, não forma shell

Escaneamento de Imagem

• Escaneamento Trivy ou Grype em CI (falha em HIGH/CRITICAL)
• Hadolint passa sem avisos
• Escaneamento de segredos executado na imagem (trivy --scanners secret)
• SBOM gerado e armazenado
• .trivyignore tem entradas justificadas para CVEs aceitos

Runtime

• Sistema de arquivos --read-only
• --cap-drop ALL (adicione de volta apenas o que é documentado como necessário)
• --security-opt no-new-privileges:true
• --security-opt seccomp=<profile> aplicado
• Limites de recursos definidos (--memory, --cpus, --pids-limit)
• Imagem assinada com Cosign; verificada antes da implantação

Kubernetes

• readOnlyRootFilesystem: true
• allowPrivilegeEscalation: false
• runAsNonRoot: true com UID explícito
• capabilities.drop: ["ALL"]
• requests e limits de recursos definidos
• automountServiceAccountToken: false
• PSA de namespace imposta no nível restricted
• NetworkPolicy default-deny aplicado
• RBAC usa nomes de recursos específicos e verbos mínimos

Limitações

• Use esta habilidade apenas quando a tarefa corresponder claramente ao escopo descrito acima.
• Não trate a saída como substituta para testes de penetração específicos do ambiente ou uma auditoria de segurança formal.
• Perfis Seccomp e AppArmor são apenas para Linux; Docker Desktop para macOS/Windows usa mecanismos diferentes.
• Pare e peça esclarecimentos se os inputs necessários, permissões, limites de segurança ou critérios de sucesso estiverem faltando.