A Docker védelme több szinten történik — minimális és megbízható images, non-root felhasználóként futtatás, sebezhetőségi vizsgálat, titkos adatok kezelése, erőforrás és capability korlátozások, valamint host/daemon hardening. A konténer biztonsága fontos, mert a sebezhetőségek a konténert és a hosztot egyaránt érinthetik.
✓ 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
A Docker konténerek védelme senior szintű fontos tudás, mivel a konténer sebezhetőségek a konténert és a hosztot egyaránt érinthetik, így a biztonság multi-rétegű probléma, amely valós következményekkel jár. Az image biztonsági gyakorlatok (minimális/megbízható alképek az támadási felület csökkentéséhez, verziók rögzítése, sebezhetőségi vizsgálat az ismert CVE-k azonosításához, images naprakészen tartása) megakadályozzák a kihasználható images szállítását — amely a sebezhetőségek gyakori forrása. A runtime biztonság különösen kritikus: a non-root felhasználóként futtatás az egyik legfontosabb gyakorlat, mert egy kompromittált root konténer sokkal veszélyesebb (potenciálisan a host sérüléséhez vezethet), és a capabilities eldobása, csak olvasható fájlrendszerek, a jogok kiterjesztésének megakadályozása, valamint a --privileged soha ne használd hacsak nem feltétlenül szükséges (majdnem teljes host hozzáférést ad) mind korlátozza, mit tehet egy támadó, ha egy konténer megsérül — többrétegű védelem. A titkos adatok kezelése (soha ne égess be titkokat az imagesbke, használj runtime titkokat) megakadályozza a hitelesítési adatok kiszivárgását. A host és daemon biztonság döntő fontosságú és gyakran figyelmen kívül hagyott: a Docker daemon root-ként fut, így a hozzáférés rá (vagy a Docker sockethez) gyakorlatilag root a hoszt számára — így a daemon védelme, a Docker socket nem közvetítése, valamint a host frissítésének aktuális tartása alapvető, a rootless Docker és user namespaces erősebb izolációt kínálva.
Mivel a konténerek megosztják a host kernelt (így a konténerből való kiesés vagy host kompromittálódás súlyos következményekkel jár) és a containerizált alkalmazások széles körben elterjedtek az éles üzemben, és mivel a megfelelő biztonság (minimális/vizsgált imagesk, non-root futtatás korlátozott capabilitykkel, titkos adatok kezelése, daemon/host hardening) az, ami megakadályozza a valós konténer és host kompromittálódásokat, a Docker konténerek biztonságáról való tudás senior szintű fontos tudás — a termelésben futó konténer telepítések kritikus felelőssége, ahol a rétegzett gyakorlatok (különösen a non-root futtatás és a root-jogosultságú daemon védelme) a containerizációban rejlő valós, komoly biztonsági kockázatokra adnak választ.