Die Sicherung von Docker umfasst mehrere Schichten — minimale und vertrauenswürdige Images, Ausführung als Nicht-Root, Schwachstellenscans, Secrets-Management, Ressourcen- und Capability-Limits sowie Host-/Daemon-Härtung. Container-Sicherheit ist wichtig, da Schwachstellen sowohl den Container als auch den Host beeinträchtigen können.
✓ 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
Die Sicherung von Docker-Containern ist wichtiges Wissen auf Senior-Level, da Container-Schwachstellen sowohl den Container als auch den Host beeinträchtigen können, was Sicherheit zu einer mehrstufigen Angelegenheit mit echten Konsequenzen macht. Image-Sicherheit-Praktiken (minimale/vertrauenswürdige Base-Images, um die Angriffsfläche zu reduzieren, Versions-Pinning, Scans auf Schwachstellen, um bekannte CVEs zu finden, Images aktuell halten) verhindern, dass ausnutzbare Images versendet werden — eine häufige Quelle von Schwachstellen. Runtime-Sicherheit ist besonders kritisch: Ausführung als Nicht-Root ist eine der wichtigsten Praktiken, da ein kompromittierter Root-Container viel gefährlicher ist (potenziell führt dies zu Host-Kompromittierung), und Capabilities zu entfernen, Dateisysteme schreibgeschützt zu machen, Privilege Escalation zu verhindern und niemals --privileged zu verwenden, es sei denn, es ist absolut notwendig (es gewährt nahezu Host-Zugriff), all das limitiert, was ein Angreifer tun kann, wenn ein Container kompromittiert wird — Defense in Depth. Secrets-Management (nie Secrets in Images zu backen, Laufzeit-Secrets zu nutzen) verhindert Credential-Lecks. Host- und Daemon-Sicherheit ist entscheidend und oft übersehen: Der Docker Daemon läuft als Root, daher bedeutet Zugriff darauf (oder auf den Docker-Socket) effektiv Root auf dem Host — was den Daemon schützen, den Docker-Socket nicht exponieren und den Host aktuell halten essenziell macht, wobei Rootless Docker und User Namespaces stärkere Isolation bieten.
Da Container den Host-Kernel teilen (ein Container Escape oder Host-Kompromittierung hat also ernsthafte Konsequenzen) und containerisierte Anwendungen in der Produktion verbreitet sind, und da richtige Sicherheit (minimale/gescannte Images, Non-Root-Laufzeit mit limitierten Capabilities, Secrets-Management und Daemon-/Host-Härtung) echte Container- und Host-Kompromittierungen verhindert, ist das Verständnis, wie Docker-Container zu sichern sind, wichtiges Senior-Level-Wissen — eine kritische Verantwortung für produktive Container-Deployments, wobei die mehrstufigen Praktiken (besonders Non-Root-Ausführung und der Schutz des Root-privilegierten Daemon) echte, ernsthafte Sicherheitsrisiken, die der Containerisierung inhärent sind, adressieren.