Proteger Docker envolve múltiplas camadas — imagens mínimas e confiáveis, executar como non-root, varredura de vulnerabilidades, gerenciamento de secrets, limites de recursos e capacidades e hardening de host/daemon. A segurança de containers é importante porque vulnerabilidades podem afetar tanto o container quanto o host.
✓ Use MINIMAL base images (alpine, distroless) → fewer packages = smaller attack surface
✓ Use TRUSTED/official images; pin specific versions/DIGESTS (not "latest")
✓ SCAN images for vulnerabilities (Trivy, docker scout, Snyk) — in CI and regularly
✓ Keep base images UPDATED (patch known CVEs)
✓ Don't include secrets or unnecessary tools in images
✓ Run as NON-ROOT (USER instruction) — a root container that's compromised is far more
dangerous (especially with host access). This is one of the most important practices.
✓ Drop capabilities (--cap-drop ALL, add only needed ones) — limit what the container can do
✓ Read-only filesystem (--read-only) where possible
✓ no-new-privileges (prevent privilege escalation)
✓ Set RESOURCE LIMITS (prevent DoS from resource exhaustion)
✓ NEVER run --privileged unless absolutely necessary (it gives near-host access)
✓ Don't bake secrets into images; use secrets management at runtime
✓ Protect the DOCKER DAEMON — the daemon runs as root; access to it = root on the host
(don't expose the Docker socket; mounting /var/run/docker.sock into a container is risky)
✓ Keep the host and Docker engine PATCHED; use minimal/hardened host OS
✓ Isolate networks; limit container-to-container and container-to-host access
✓ Consider rootless Docker / user namespaces for stronger isolation
Proteger containers Docker é conhecimento importante de nível sênior porque vulnerabilidades de containers podem afetar tanto o container quanto o host, tornando a segurança uma preocupação com múltiplas camadas e consequências reais. As práticas de segurança de imagens (imagens base mínimas/confiáveis para reduzir superfície de ataque, fixar versões, varrer por vulnerabilidades para detectar CVEs conhecidas, manter imagens atualizadas) evitam enviar imagens exploráveis — uma fonte comum de vulnerabilidades. A segurança em tempo de execução é especialmente crítica: executar como non-root é uma das práticas mais importantes porque um container root comprometido é muito mais perigoso (potencialmente levando ao comprometimento do host), e descartar capacidades, usar sistemas de arquivos somente leitura, prevenir escalação de privilégios e nunca usar --privileged a menos que absolutamente necessário (concede acesso quase ao nível do host) limitam o que um atacante pode fazer se um container é violado — defesa em profundidade. O gerenciamento de secrets (nunca incorporar secrets em imagens, usar secrets em tempo de execução) previne vazamento de credenciais. A segurança de host e daemon é crucial e frequentemente negligenciada: o Docker daemon é executado como root, então o acesso a ele (ou ao Docker socket) efetivamente significa root no host — tornando a proteção do daemon, não expor o Docker socket e manter o host corrigido essencial, com Docker rootless e namespaces de usuário oferecendo isolamento mais forte.
Como containers compartilham o kernel do host (então um escape de container ou comprometimento do host tem consequências sérias) e aplicações containerizadas são onipresentes em produção, e como a segurança adequada (imagens mínimas/verificadas, runtime non-root com capacidades limitadas, gerenciamento de secrets e hardening de daemon/host) é o que previne compromissos reais de container e host, entender como proteger containers Docker é conhecimento importante de nível sênior — uma responsabilidade crítica para deployments de containers em produção, onde as práticas em camadas (especialmente execução non-root e proteção do daemon privilegiado root) abordam riscos de segurança genuínos e sérios inerentes à containerização.