La protezione di Docker comporta molteplici livelli — immagini minime e fidate, esecuzione come non-root, scansione delle vulnerabilità, gestione dei segreti, limiti di risorse e capacità, e hardening dell'host/daemon. La sicurezza dei container è importante perché le vulnerabilità possono interessare sia il container che l'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
La protezione dei container Docker è una conoscenza importante a livello senior perché le vulnerabilità dei container possono interessare sia il container che l'host, rendendo la sicurezza una preoccupazione multi-livello con conseguenze reali. Le pratiche di sicurezza delle immagini (immagini base minime/fidate per ridurre la superficie d'attacco, pinning delle versioni, scansione delle vulnerabilità per rilevare CVE noti, mantenere le immagini aggiornate) prevengono di spedire immagini sfruttabili — una fonte comune di vulnerabilità. La sicurezza a runtime è particolarmente critica: l'esecuzione come non-root è una delle pratiche più importanti perché un container root compromesso è molto più pericoloso (potenzialmente portando al compromesso dell'host), e rilasciare le capacità, utilizzare filesystem read-only, prevenire l'escalation dei privilegi, e non utilizzare mai --privileged a meno che non sia assolutamente necessario (concede accesso quasi al livello dell'host) limitano tutto ciò che un attaccante può fare se un container viene violato — difesa in profondità. La gestione dei segreti (non incorporare segreti nelle immagini, utilizzare segreti a runtime) previene fughe di credenziali. La sicurezza dell'host e del daemon è cruciale e spesso trascurata: il daemon Docker viene eseguito come root, quindi l'accesso ad esso (o al socket Docker) significa effettivamente root sull'host — rendendo essenziale proteggere il daemon, non esporre il socket Docker, e mantenere l'host patchato, con Docker rootless e user namespaces che offrono un isolamento più forte.
Poiché i container condividono il kernel dell'host (quindi un escape del container o un compromesso dell'host ha conseguenze serie) e le applicazioni containerizzate sono diffuse in produzione, e poiché la corretta protezione (immagini minime/scansionate, runtime non-root con capacità limitate, gestione dei segreti, e hardening del daemon/host) è ciò che previene veri compromessi di container e host, comprendere come proteggere i container Docker è una conoscenza importante a livello senior — una responsabilità critica per i deployment di container in produzione, dove le pratiche multi-livello (in particolare l'esecuzione non-root e la protezione del daemon privilegiato come root) affrontano rischi di sicurezza genuini e seri inerenti alla containerizzazione.