Docker Penetration Testing · Moritz Samrock

Docker Penetration Testing ist die autorisierte, methodische Sicherheitsprüfung von Docker-Hosts, Containern, Images und der umgebenden Infrastruktur. Ziel ist es, ausnutzbare Schwachstellen und Fehlkonfigurationen zu identifizieren, die einem Angreifer erlauben könnten, aus einem Container auszubrechen, den Host zu kompromittieren, sensible Daten aus Image-Layern zu extrahieren oder sich über containerisierte Services hinweg zu bewegen.

Docker bietet zwar prozessbasierte Isolation, teilt jedoch den Host-Kernel mit allen Containern. Eine einzige Fehlkonfiguration — ein gemounteter Docker Socket, ein privilegierter Container oder eine exponierte Daemon-API — kann die gesamte Isolationsgrenze aufheben. Ein Docker Pentest prüft, ob diese Grenzen einem entschlossenen Angreifer standhalten.

Wer beauftragt diesen Test?

DevOps-Teams, Platform Engineers, Application-Security-Teams und CISOs sind die typischen Auftraggeber. Organisationen, die containerbasierte Deployment-Pipelines aufbauen, Docker in Produktion betreiben oder von virtuellen Maschinen auf Container migrieren, beauftragen diese Tests zur Validierung, dass die Containerisierung keine neuen Angriffspfade einführt. Compliance-Anforderungen nach PCI DSS, SOC 2 oder ISO 27001 erwarten zunehmend den Nachweis, dass Container-Umgebungen unabhängig geprüft wurden.

Ziel des Tests

Das primäre Ziel ist die Identifikation ausnutzbarer Schwachstellen in der Docker-Umgebung und die Bewertung ihrer realen Auswirkungen. Dies umfasst die Prüfung, ob ein Angreifer, der einen einzelnen Container kompromittiert hat, auf den Host ausbrechen, auf andere Container zugreifen, Secrets aus Image-Layern auslesen oder den Docker Daemon für eine vollständige Host-Übernahme nutzen kann. Tester liefern konkrete Behebungsempfehlungen für jeden Befund.

Was wird getestet?

Die Prüfung umfasst die gesamte Angriffsfläche eines Docker-Deployments: Docker-Daemon-Konfiguration und API-Exposition (TCP 2375/2376), Container-Runtime-Sicherheit (Privilegien, Capabilities, seccomp- und AppArmor-Profile), Volume-Mount-Konfigurationen (Host-Dateisystem, Docker Socket), Image-Sicherheit (Base-Image-Schwachstellen, Secrets in Layern, Dockerfile-Best-Practices), Netzwerkkonfiguration (Bridge-Networking, Inter-Container-Kommunikation), User Namespace Remapping, Read-Only Root Filesystem Enforcement, Resource Limits (CPU, Memory, PIDs), Container-to-Host-Escape-Pfade über Kernel-Exploits oder Fehlkonfigurationen, Docker-Compose- und Orchestrierungskonfiguration, Registry-Sicherheit und Image-Provenienz sowie Logging- und Monitoring-Abdeckung.

Übliche Schwachstellen und Findings

Typische Schwachstellen umfassen den Docker Socket (/var/run/docker.sock), der in Container gemountet wird und damit volle Kontrolle über den Docker Daemon und effektiv vollständige Host-Kompromittierung ermöglicht, privilegierte Container mit allen Linux Capabilities und ohne Isolation vom Host, Container, die intern als Root laufen ohne User Namespace Remapping, sensible Daten (API-Keys, Passwörter, Zertifikate), die über ENV, ARG oder COPY in Docker-Image-Layer eingebettet sind, exponierte Docker-Daemon-API auf TCP 2375 (unverschlüsselt) oder 2376 (TLS) ohne ordnungsgemäße Authentifizierung, Host-Dateisystempfade als Volumes gemountet mit Lese-/Schreibzugriff auf kritische Systemverzeichnisse, fehlende seccomp- oder AppArmor-Profile, die Containern gefährliche Systemaufrufe erlauben, veraltete Base Images mit bekannten CVEs, die nicht neu gebaut wurden, Container-to-Host-Escape über Kernel-Exploits auf geteilten Kernel-Versionen, fehlendes Read-Only Root Filesystem, das Angreifern die Modifikation von Container-Inhalten zur Laufzeit erlaubt, übermäßige Container-Capabilities (z. B. CAP_SYS_ADMIN, CAP_NET_RAW) und fehlende Resource Limits, die Denial of Service durch Fork Bombs oder Speichererschöpfung ermöglichen.

Ablauf eines Docker Penetrationstests

Ein Docker Penetrationstest folgt einem strukturierten Prozess von der Erstanfrage bis zum Projektabschluss.

Interesse und Erstanfrage — der Kunde nimmt Kontakt auf und beschreibt seine Docker-Umgebung, die Anzahl der Hosts, die Art der Container-Orchestrierung und den geschäftlichen Anlass.

Erstgespräch zum Verständnis der Kundenziele — Tester und Kunde besprechen die Container-Architektur, die Docker-Version, das Orchestrierungs-Tooling (Standalone Docker, Docker Compose, Swarm), die Hosting-Umgebung und ob die CI/CD-Pipeline, die Images baut, einbezogen werden soll. Daraus entsteht die Aufwandsschätzung.

Angebotserstellung und Freigabe — ein formales Angebot wird erstellt mit Scope, Methodik, Zeitplan, Deliverables und Preisgestaltung. Der Kunde prüft und gibt frei.

Scope-Definition — die genauen Ziele werden dokumentiert: Docker-Hosts, spezifische Container oder Services, Registries, CI/CD-Pipelines und etwaige Einschränkungen (z. B. Produktionscontainer von destruktivem Testen ausgenommen).

Letter of Engagement — ein rechtlich bindendes Dokument autorisiert den Test, regelt Haftung, Notfallkontakte und Kommunikationswege. Dies schützt beide Seiten und ist besonders wichtig, wenn das Testen laufende Services beeinträchtigen könnte.

Erstellung weiterer Freigaben — laufen die Docker-Hosts in einer Cloud-Umgebung, muss die Penetrationstest-Policy des Cloud-Providers geprüft werden. Einige Provider verlangen eine Benachrichtigung. Sind Drittanbieter-Base-Images oder Registries im Scope, kann eine separate Autorisierung erforderlich sein.

Bereitstellung von Informationen je nach Black-/Gray-/White-Box-Ansatz — je nach gewähltem Ansatz stellt der Kunde SSH-Zugang zu Docker-Hosts, Dockerfiles, Docker-Compose-Dateien, Registry-Zugangsdaten oder Architekturdiagramme bereit. Gray-Box-Testing mit Shell-Zugang innerhalb eines Containers ist üblich und simuliert eine kompromittierte Anwendung.

Kick-Off Call — Tester, DevOps Engineers und Stakeholder stimmen Logistik, Eskalationswege, Testfenster und Kommunikationsrhythmus ab.

Durchführung mit laufender Information der Stakeholder — die Tester bewerten die Docker-Umgebung systematisch und versuchen Container Escape, Privilegieneskalation und laterale Bewegung. Kritische Findings wie Docker-Socket-Exposition oder Host-Dateisystemzugriff werden umgehend gemeldet.

Sammlung und Bewertung der Schwachstellen — alle Findings werden mit Reproduktionsschritten, Befehlen, Nachweisen (Terminal-Output, Screenshots) und einer Schweregradbewertung dokumentiert, die Ausnutzbarkeit und Auswirkung kombiniert.

Erstellung des Abschlussberichts — ein umfassender Bericht enthält eine Management Summary, detaillierte technische Findings, Risikobewertungen und spezifische Behebungsempfehlungen einschließlich Dockerfile-Korrekturen, Daemon-Konfigurationsänderungen und Runtime-Policy-Beispiele.

Vorstellung in einer Präsentation — die Ergebnisse werden sowohl dem DevOps-Team als auch dem Management vorgestellt, mit Erklärung der Findings, ihrer Auswirkungen und priorisierter Behebungsschritte.

Projektabschluss — das Engagement wird formal abgeschlossen. Ein Retest wird typischerweise vereinbart, nachdem der Kunde die Härtungsmaßnahmen umgesetzt hat.

Wer sollte diesen Test wann durchführen lassen?

Jede Organisation, die Docker in Produktion einsetzt, sollte Docker Penetrationstests beauftragen. Typische Anlässe sind der Zeitpunkt vor dem Go-Live containerisierter Deployments, nach Docker-Engine- oder Host-OS-Updates, bei der Einführung neuer Base Images oder Registries, nach Änderungen an der Container-Orchestrierung oder Runtime-Konfiguration, als Teil eines umfassenderen Container-Security-Programms und mindestens jährlich als Baseline. Organisationen, die sensible Daten verarbeiten oder in regulierten Branchen operieren, sollten häufiger testen und Container-Sicherheitstests in ihre CI/CD-Pipeline integrieren.