OWASP Docker Security Sheet

REGEL 0 – Host und Docker auf dem neuesten Stand halten

• Erklärung: Container teilen sich den Kernel mit dem Host. Kernel-Exploits im Container wirken direkt auf den Host.
• Risiko: Ein Angreifer kann über Schwachstellen wie „Dirty COW“ Root-Rechte auf dem Host erlangen.
• Best Practice: Regelmäßige Updates von Docker Engine, Docker Machine und Linux-Kernel einspielen, Security Advisories abonnieren.

REGEL 1 – Docker-Daemon-Socket nicht freigeben

• Erklärung: /var/run/docker.sock ist der Einstiegspunkt zur Docker-API – Besitzer = root.
• Risiko: Jeder mit Zugriff auf diesen Socket hat vollen Root-Zugriff auf den Host.
• Beispiel: Viele Images binden den Socket per „-v /var/run/docker.sock:/var/run/docker.sock“ ein → Privilege Escalation.
• Best Practice: Socket niemals in Container mounten. Falls Remote-Zugriff nötig: TLS-gesicherter TCP-Socket mit Authentifizierung.

REGEL 2 – Benutzer festlegen

• Erklärung: Standardmäßig läuft der Container-Prozess als root.
• Risiko: Kompromittierte Container-Prozesse können mit Root-Rechten auf Host-Ressourcen zugreifen.
• Best Practice:
  • Im Dockerfile mit „USER“ setzen.
  • User Namespaces aktivieren (–userns-remap).
  • In Kubernetes runAsNonRoot verwenden.

REGEL 3 – Fähigkeiten beschränken

• Erklärung: Linux Capabilities sind granulare Root-Rechte (z. B. CHOWN, NET_ADMIN).
• Risiko: Container mit „--privileged“ oder unnötigen Capabilities können Kernel-Operationen durchführen.
• Best Practice:
  • Standardmäßig „--cap-drop all“ setzen, nur benötigte hinzufügen.
  • Niemals „--privileged“ nutzen.
  • In Kubernetes: capabilities im SecurityContext definieren.

REGEL 4 – no-new-privileges setzen

• Erklärung: Verhindert, dass Prozesse durch setuid/setgid zusätzliche Rechte erlangen.
• Risiko: Ohne dieses Flag können Programme Rechte-Eskalation durchführen.
• Best Practice: Container mit „--security-opt=no-new-privileges“ starten, in Kubernetes allowPrivilegeEscalation=false.

REGEL 5 – Inter-Container-Kommunikation deaktivieren

• Erklärung: Standardmäßig können Container über das docker0-Bridge-Netzwerk miteinander kommunizieren.
• Risiko: Kompromittierter Container kann andere Container angreifen oder scannen.
• Best Practice: Docker mit „--icc=false“ starten, Kommunikation nur explizit erlauben. In Kubernetes: NetworkPolicies nutzen.

REGEL 6 – Linux-Sicherheitsmodule nutzen

• Erklärung: Seccomp, AppArmor, SELinux beschränken Systemaufrufe und Zugriffe von Prozessen.
• Risiko: Ohne Profile können Container auf kritische Kernel-Funktionen zugreifen.
• Best Practice: Standardprofile nicht deaktivieren, eigene Policies erstellen und strikt einsetzen.

REGEL 7 – Ressourcen begrenzen

• Erklärung: Container können sonst unbeschränkt CPU, RAM, File-Deskriptoren nutzen.
• Risiko: DoS-Angriffe möglich, Host wird überlastet.
• Best Practice: Ressourcenlimits per „--memory“, „--cpu-shares“, „--ulimit“ setzen. In Kubernetes: Resource Limits definieren.

REGEL 8 – Dateisysteme schreibgeschützt mounten

• Erklärung: Container-Filesystem standardmäßig beschreibbar.
• Risiko: Malware kann Dateien manipulieren, Persistenz aufbauen.
• Best Practice:
  • „--read-only“ nutzen.
  • Schreibrechte nur für explizite tmpfs-Mounts.
  • Volumes mit „:ro“ oder „readonly“ einbinden.

REGEL 9 – Statische Analysetools einsetzen

• Erklärung: Container-Images können bekannte CVEs enthalten.
• Risiko: Deployment von Images mit kritischen Sicherheitslücken.
• Best Practice:
  • Tools wie Trivy, Clair, Anchore, Snyk oder Grype nutzen.
  • In CI/CD-Pipeline integrieren.

REGEL 10 – Logging konfigurieren

• Erklärung: Docker loggt standardmäßig auf „info“-Level.
• Risiko: Wichtige Ereignisse fehlen oder Debug-Level erzeugt unnötige Datenmengen.
• Best Practice:
  • Mindestens „info“-Level aktivieren.
  • Zentrale Log-Sammlung über ELK, Loki oder SIEM.

REGEL 11 – Dockerfile absichern

• Erklärung: Schlechte Praktiken im Dockerfile führen zu unsicheren Images.
• Risiko: Root-User, ungepatchte Basis-Images, Curl-Bashing, unfixierte Versionen.
• Best Practice:
  • Immer „USER“ definieren.
  • Basis-Images versionieren.
  • COPY statt ADD verwenden.
  • Dockerfile mit Lintern prüfen (z. B. hadolint).