Ich habe eine kleine Lab-Umgebung gebaut, um zu sehen, wie Container-Fehlkonfigurationen zu Host-Zugriff führen können. Ziel war kein neuer Exploit, sondern ein besseres Gefühl für die praktischen Folgen typischer Konfigurationsfehler.
Container wirken stark isoliert — diese Isolation hängt aber massiv von der Konfiguration ab. Privileged Mode, geteilte Namespaces oder riskante Mounts können die Grenze zwischen Container und Host deutlich verwässern.
Das Lab enthielt absichtlich schwache Setups:
- Container mit
--privileged. - Zugriff auf den PID-Namespace des Hosts.
- Gemounteter Docker-Socket.
- Beschreibbare Mounts mit Host-Verzeichnissen.
Jede Variante zeigt einen anderen Weg zur Interaktion mit dem Host.
Beispiel Docker-Socket: Prozesse im Container können damit weitere Container auf dem Host starten — mit erhöhten Rechten oder Host-Mounts wird das faktisch Host-Zugriff.
Geteilte Namespaces bringen andere Risiken: Mit Host-PID können Container-Prozesse Host-Prozesse direkt sehen und inspizieren.
Ich habe auch angeschaut, wie cgroups und System-Schnittstellen von innen wirken — das verdeutlicht, wie Runtimes Isolation erzwingen und wo sie bei Fehlkonfiguration nachgibt.
Keine der Techniken ist neu; sie sind in der Container-Security gut dokumentiert.
Der Wert des Labs ist praktisches Verständnis. Schritt für Schritt durch die Umgebung zu gehen schärft das Modell im Kopf stärker als nur Theorie.
Übrig bleibt eine wiederverwendbare Umgebung für Demos, Experimente und Erklärungen, wie Konfigurationswahl die Container-Security beeinflusst.