Sikring af Docker involverer flere lag — minimale og pålidelige images, kørsel som ikke-root, sårbarhedsskanning, hemmeligheder management, ressource- og capability-begrænsninger og værtsmaskine/daemon-hardening. Container-sikkerhed er vigtig, fordi sårbarheder kan påvirke både containeren og værtsmaskinenen.
✓ 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
Sikring af Docker-containere er vigtig senior-level-viden, fordi container-sårbarheder kan påvirke både containeren og værtsmaskinenen, hvilket gør sikkerhed til et multi-lagdelt problem med virkelige konsekvenser. Image-sikkerhed-praksis (minimale/pålidelige base-images for at reducere angrebsoverfladen, fastlåsning af versioner, skanning for sårbarheder for at fange kendte CVE'er, hold images opdateret) forhindrer i at sende eksploiterbare images — en almindelig kilde til sårbarheder. Runtime-sikkerhed er særlig kritisk: kørsel som ikke-root er en af de vigtigste praksis, fordi en kompromitteret root-container er meget mere farlig (potentielt førende til værtsmaskinekompromis), og fjernelse af capabilities, brug af read-only-filsystemer, forhindring af privilege escalation, og aldrig brug af --privileged medmindre det er absolut nødvendigt (det giver næsten-værtsmaskine-adgang) begranser alle det, som en angriber kan gøre, hvis en container bliver compromitteret — defense in depth. Hemmeligheder management (aldrig bage hemmeligheder ind i images, brug runtime-hemmeligheder) forhindrer legitimationslækker. Værtsmaskine- og daemon-sikkerhed er afgørende og ofte overset: Docker-daemonen kører som root, så adgang til den (eller Docker-socketen) betyder effektivt root på værtsmaskinenen — hvilket gør det at beskytte daemonen, ikke at udsætte Docker-socketen, og hold værtsmaskinenen patched essentiel, med rootless Docker og user namespaces der tilbyder stærkere isolering.
Fordi containere deler værtsmaskinekjernen (så en container escape eller værtsmaskinekompromis har alvorlige konsekvenser) og containeriserede applikationer er udbredt i produktion, og fordi korrekt sikkerhed (minimale/scannede images, ikke-root runtime med begrænsede capabilities, hemmeligheder management, og daemon/værtsmaskine-hardening) er det, der forhindrer virkelige container- og værtsmaskine-kompromisetter, er forståelse af, hvordan man sikrer Docker-containere, vigtig senior-level-viden — et kritisk ansvar for produktionscontainerdistributioner, hvor de lagdelte praksis (især ikke-root-udførelse og beskyttelse af den root-privilegeret daemon) addresserer ægte, alvorlige sikkerhedsrisici, der er iboende for containerisering.