Gut isoliert

von Stefan Mutschler

Container treiben die Cloudrevolution – doch ihre Sicherheit ist fragil. Immer häufiger gelingt es Angreifern, die Isolation der Container zu durchbrechen. Solche "Container Escapes" zählen zu den gefährlichsten Bedrohungen moderner IT und können im Extremfall ganze (Cloud-) Infrastrukturen ins Wanken bringen. Wo potenzielle Schwachstellen liegen, wie Angreifer vorgehen und wie eine solide Verteidigung aussieht, zeigt dieser Artikel.

Container haben sich in den vergangenen Jahren zu einem der wichtigsten Bausteine moderner IT-Infrastrukturen entwickelt. Sie beanspruchen verhältnismäßig wenig Systemressourcen, sind übersichtlich, flexibel und ermöglichen es, Anwendungen schnell zu entwickeln, bereitzustellen und zu skalieren. Ob in Cloudumgebungen, im DevOps-Kontext oder in klassischen Rechenzentren – Container sind heute allgegenwärtig. Doch mit ihrer wachsenden Bedeutung steigt auch das Interesse von Angreifern.

Ein besonders kritisches Szenario ist dabei der sogenannte „Container Escape“: Der Moment, in dem ein Angreifer die eigentlich vorgesehene Isolationsschicht durchbricht und so Zugriff auf das Hostsystem oder andere Container erlangt. Damit ist nicht nur die Sicherheit der einzelnen Anwendung gefährdet, sondern oft die gesamte darunterliegende Infrastruktur. Wer Container sicher betreiben will, muss deshalb verstehen, wie ein Container Escape technisch funktioniert und welche Maßnahmen IT-Administratoren konkret ergreifen sollten, um das Risiko auf ein Minimum zu reduzieren. Ein Blick auf reale Fälle der jüngeren Vergangenheit liefert Hinweise, wie sich Container-Umgebungen so härten lassen, dass selbst raffinierte Escape-Techniken ins Leere laufen.

Wie Container Anwendungen isolieren

Container wirken nach außen fast so, als wären sie eine eigene kleine virtuelle Maschine (VM) mit eigenem Dateisystem, eigenen Prozessen und eigenem Netzwerk. Tatsächlich laufen sie jedoch alle auf demselben Betriebssystem-Kernel des Hosts. Der Eindruck der scharfen Trennung entsteht durch mehrere Mechanismen des Linux-Kernels, die zusammenspielen und gemeinsam eine Art "virtuelle Umgebung" schaffen.

Namespaces sind das zentrale Werkzeug für die Isolation. Sie sorgen dafür, dass ein Container nur das "sieht", was für ihn vorgesehen ist. Jeder Namespace bildet eine Art abgeschotteten Raum für bestimmte Ressourcen:

- PID-Namespace: Prozesse im Container sehen nur die eigenen Prozess-IDs, nicht die Prozesse auf dem Host oder in anderen Containern.

- Mount-Namespace: Jeder Container hat sein eigenes Overlay-Dateisystem. Auch wenn mehrere Container auf demselben Host laufen, sieht jeder nur seine "Welt".

- Network-Namespace: Container bekommen eigene virtuelle Netzwerkinterfaces, IP-Adressen und Routingtabellen. Sie sind dadurch wie eigenständige Hosts im Netzwerk.

- UTS-Namespace: Container können ihren eigenen Hostnamen und Domainnamen verwenden, ohne den des Hosts zu verändern.

- IPC-Namespace: Mechanismen zur Interprozesskommunikation (Shared Memory, Message Queues) sind isoliert. Prozesse im Container dürfen nur mit Prozessen im selben Namespace kommunizieren.

Damit erzeugt der Kernel für jeden Container eine Art Blase, innerhalb derer er Ressourcen exklusiv wahrnimmt.

Control Groups und Root-Rechte

Neben der Sicht auf Ressourcen ist auch deren Nutzung entscheidend. Control Groups, kurz cgroups, erlauben es, Containern feste Limits für CPU, Arbeitsspeicher, Netzwerkbandbreite oder IO-Kapazität zuzuweisen. Das verhindert, dass ein Container sämtliche Ressourcen des Hosts verbraucht und andere Anwendungen zum Stillstand bringt. cgroups sind also die Basis für Fairness und Stabilität in Multi-Container-Umgebungen.

Traditionell bedeuteten Root-Rechte unter Linux uneingeschränkte Macht. Mit Capabilities lassen sich diese Rechte in kleinere Einheiten aufteilen. Container erhalten in der Regel nur einen kleinen Satz von Standard-Capabilities, etwa um Ports unterhalb von 1024 zu binden. Rechte, die eine Gefahr darstellen könnten, wie das Mounten von Dateisystemen oder das Laden von Kernelmodulen, bleiben verwehrt. Dadurch laufen Anwendungen im Container mit reduzierten, genau zugeschnittenen Berechtigungen.

Dateisysteme isolieren

Container nutzen meist ein Union Filesystem (OverlayFS), das mehrere Schichten übereinanderlegt. Das Basisimage ist "read-only" und für alle Container gleich. Änderungen wie Konfigurationsdateien oder Logs landen in einer beschreibbaren Schicht darüber. So bekommt jeder Container den Eindruck eines vollständigen, eigenen Dateisystems – ohne dass tatsächlich jedes Mal die Installation eines kompletten Betriebssystems anfällt.

Mechanismen wie AppArmor, SELinux (Security-Enhanced Linux) oder Seccomp (Secure Computing Mode) ergänzen die Isolation. Sie setzen zusätzliche Richtlinien durch, etwa welche Dateien ein Container überhaupt sehen darf oder welche Systemaufrufe er nutzen darf. Das ist sozusagen die zweite Verteidigungslinie, falls ein Angreifer die grundlegende Namespace-Isolation umgeht.

Sicherheitsmodule als zweite Verteidigungslinie

Namespaces und cgroups bilden die Basis der Container-Isolation. Doch sie sind nicht unfehlbar: Durch das Ausnutzen eines Fehlers etwa im Kernel oder einer Container-Runtime können Angreifer die vorgesehenen Grenzen durchbrechen. Hier kommen Mandatory-Access-Control-(MAC)-Mechanismen ins Spiel. Mit Werkzeugen wie AppArmor, SELinux und Seccomp stellt Linux zusätzliche Sicherheitsbarrieren bereit, die wie eine zweite Verteidigungslinie wirken. Selbst wenn ein Angreifer es schafft, die Namespace-Isolation zu umgehen, stößt er auf weitere Schranken.

AppArmor (Application Armor) arbeitet mit sogenannten Sicherheitsprofilen, die exakt definieren, welche Aktionen ein Prozess ausführen darf. Diese Profile sind auf einen bestimmten Container anwendbar. Typische Regeln betreffen:

- zugängliche Dateien oder Verzeichnisse,

- erlaubte Netzwerkoperationen und

- ansprechbare Systemressourcen.

Ein Beispiel: Ein Container, der nur Webinhalte ausliefert, benötigt keinen Zugriff auf "/etc/shadow". Mit AppArmor lässt sich dies strikt verbieten. Versucht ein Prozess dennoch, auf eine gesperrte Ressource zuzugreifen, schlägt der Zugriff fehl oder landet zumindest im Log. AppArmor setzt dabei auf ein Whitelist-Prinzip: Nur was ausdrücklich erlaubt ist, ist zulässig.

SELinux verfolgt einen noch systematischeren Ansatz. Es basiert auf einer Label-Logik: Jede Datei, jeder Prozess und jede Ressource im System erhält ein Sicherheitslabel. Regeln in der sogenannten Policy bestimmen, welche Labels miteinander interagieren dürfen. Selbst wenn ein Prozess durch einen Container Escape Zugriff auf das Hostsystem erhält, darf er dort nicht automatisch alles lesen oder schreiben. Nur die Interaktionen, die durch die Policy erlaubt sind, sind möglich. Ein Container-Prozess mit dem Label "svirt_lxc_net_t" etwa darf vielleicht auf sein eigenes Dateisystem zugreifen, nicht aber auf Dateien mit dem Label "system_conf_t". Dadurch entsteht eine feingranulare, verpflichtende Zugriffskontrolle, die unabhängig von den klassischen Unix-Rechten funktioniert.

Seccomp greift auf einer noch niedrigeren Ebene an. Jeder Prozess kommuniziert mit dem Kernel über System Calls (Syscalls). Diese Schnittstelle ist ein beliebtes Angriffsziel, weil Prozesse über sie unter anderem Speicher, Dateien oder Netzwerkressourcen ansprechen. Seccomp ermöglicht es, die Zahl erlaubter Systemaufrufe massiv zu reduzieren. Statt dem Prozess sämtliche mehrere Hundert Linux-Syscalls zu erlauben, stellen Sie ihm nur eine kleine, sichere Auswahl zur Verfügung. Ein Container, der lediglich HTTP-Anfragen beantwortet, braucht keinen Zugriff auf "ptrace" (Prozess-Debugging) oder "mount" (Einbinden von Dateisystemen). Selbst bei Kompromittierung des Containers fehlen dem Angreifer so die entscheidenden Werkzeuge, um den Escape durchzuführen.

Zusammenspiel der Mechanismen

Am wirkungsvollsten sind diese Sicherheitsmodule, wenn sie kombiniert zum Einsatz kommen. AppArmor oder SELinux regeln den Zugriff auf Dateien und Ressourcen, Seccomp schränkt die erlaubten Systemaufrufe ein. Dies begrenzt den Schaden im Fall eines Angriffs:

- Ein Angreifer, der aus dem Container ausbricht, sieht möglicherweise zwar Teile des Hostsystems, darf diese aber nicht öffnen oder verändern.

- Selbst wenn er versucht, gefährliche Systemfunktionen aufzurufen, blockiert Seccomp diesen Zugriff.

- Alle Aktivitäten, die dennoch stattfinden, landen im Protokoll und lassen sich von Administratoren überwachen.

Damit stellen AppArmor, SELinux und Seccomp die zweite Verteidigungslinie dar. Sie wirken zusätzlich zur Container-Isolation – und können oft verhindern, dass ein erfolgreicher Escape auch gleich die vollständige Übernahme des Hosts bedeutet.

Wie Container Escapes funktionieren

Container schaffen also keine "echte" Hardwareisolation wie eine virtuelle Maschine. Stattdessen nutzen sie vorhandene Kernelmechanismen, um Prozessen unterschiedliche Sichten auf Ressourcen zu geben und deren Rechte einzuschränken. Während jede VM ein komplettes Gastbetriebssystem braucht, teilen sich Container den Kernel des Hostbetriebssystems. Das spart Rechenleistung und Speicherressourcen. Dadurch sind Container leichtgewichtig und effizient, aber die gemeinsame Nutzung des Kernels bleibt ein Risiko. Findet ein Angreifer dort eine Schwachstelle oder sind Konfigurationen zu großzügig ausgestaltet, kann er die Isolation durchbrechen.

Ein solcher Container Escape ist auf unterschiedlichen technischen Wegen möglich. Die wichtigsten Angriffsvektoren sind:

- Kernelschwachstellen: Da alle Container denselben Kernel nutzen, ermöglicht eine Kernelschwachstelle den Angriff auf das Hostsystem. Typische Beispiele sind fehlerhafte Implementierungen von Systemaufrufen. Gelingt es, diese auszunutzen, ist ein Angreifer nicht mehr auf seinen Container beschränkt.

- Unsichere Konfigurationen: Ein häufiger Fehler ist der Einsatz von Containern mit der Option "privileged", die praktisch sämtliche Sicherheitsbarrieren aushebelt. Ebenso riskant sind Mounts sensibler Hostverzeichnisse wie "/proc" oder "/sys".

- Fehlerhafte Handhabung von Linux-Capabilities: Linux-Capabilities erlauben es, Root-Rechte granular zu delegieren. Sind diese zu großzügig vergeben, kann ein Angreifer weitreichende Aktionen auf dem Hostsystem durchführen. Besonders gefährlich ist etwa "CAP_SYS_ ADMIN".

- Schwachstellen in Container-Runtimes: Auch Container-Engines selbst sind potenzielle Angriffsflächen. Fehler in "runc", der Docker-Engine oder Kubernetes-Komponenten etwa, wurden in der Vergangenheit mehrfach genutzt, um aus Containern auszubrechen.

- Fehlerhafte Namespaces: Sind Namespaces falsch konfiguriert oder nicht vollständig isoliert, sieht ein Container deutlich mehr vom Hostsystem, als nötig – ein idealer Ausgangspunkt für Escapes.

Vorfälle in der Praxis

Am 31. Januar 2024 veröffentlichte Snyk mehrere kritische Schwachstellen in der Container-Runtime runC, die unter dem Namen "Leaky Vessels" [1] zusammengefasst wurden. runC ist eine zentrale Komponente vieler Container-Plattformen, da es Container-Prozesse direkt auf Linux-Systemen startet. Die Sicherheitslücken ermöglichten es, aus einem Container auszubrechen und unerlaubten Zugriff auf das Hostsystem zu erlangen.

Besonders gravierend war CVE-2024-23652 mit einem CVSS-Wert von 10.0, die es Angreifern erlaubte, während der Build-Phase eines Containers beliebige Dateien zu löschen. Andere Lücken erlauben die Manipulation des Arbeitsverzeichnisses ("process.cwd") oder den Missbrauch durchgesickerter Dateideskriptoren. Alle Schwachstellen wurden vertraulich gemeldet und mit runC-Version 1.1.12 behoben. Auch wenn bislang keine Ausnutzung in freier Wildbahn bekannt ist, zeigt dieser Fall, dass Container-Runtimes ein attraktives Ziel sind.

Im April 2024 deckten Forscher von Wiz auf, dass Plattformen wie Hugging Face, die KI-Modelle als Service bereitstellen, anfällig für Container Escapes sind [2]. Durch manipulierte Modelle im Pickle-Format konnten Angreifer mieterübergreifende Angriffe (Cross-Tenant) durchführen und auf die Modelle anderer Kunden zugreifen. Das Problem: Viele Anbieter nutzen eine geteilte Inferenz-Infrastruktur, auf der Container verschiedener Kunden parallel laufen. Mit einem Escape konnten Angreifer also nicht nur ihre eigene Umgebung verlassen, sondern auch fremde Modelle stehlen oder manipulieren.

Ende Juli 2024 wurde mit CVE-2024-41110 eine Sicherheitslücke in Docker Engine mit einem CVSS-Score von 10.0 bekannt. Sie ermöglichte es, das Autorisierungs-Plug-in (AuthZ) durch speziell präparierte API-Anfragen zu umgehen. Besonders brisant: Es handelte sich um eine Regression, da dieselbe Schwachstelle bereits 2018 entdeckt und behoben worden war – jedoch später erneut unbeabsichtigt eingeführt wurde. Docker veröffentlichte kurzfristig ein Update und empfahl allen Anwendern, auf Version 4.33 oder neuer zu aktualisieren.

Auf der letzten Black Hat USA im August 2025 kam eine Schwachstelle namens "ECScape" in Amazon ECS ans Licht [3]. Sie erlaubte es Angreifern, Zugriffsrollen anderer Container auf derselben EC2-Instanz zu übernehmen. Das untergrub das Sicherheitsmodell von ECS grundlegend: Statt strikt voneinander getrennte Berechtigungen zu besitzen, konnte ein Container an privilegierte Zugangsdaten anderer Container gelangen und sich damit weitreichende Cloudberechtigungen aneignen. Damit eröffnete sich eine gefährliche Möglichkeit für seitliche Bewegungen (Lateral Movement) innerhalb der Cloudinfrastruktur.

Ebenfalls im August 2025 hat Docker eine kritische Sicherheitslücke (CVE-2025-9074, CVSS 9,3) in Docker Desktop für Windows und macOS geschlossen. Angreifer konnten die Container-Isolation durchbrechen, zusätzliche Container starten und direkten Zugriff auf den Host erlangen – selbst bei aktivierter Enhanced Container Isolation. Besonders unter Windows waren die Folgen gravierend: Ein Angreifer konnte das Dateisystem mounten, Daten auslesen und durch Manipulation einer DLL vollständige Administratorrechte übernehmen. Auch eine Ausnutzung über Server-Side-Request-Forgery war möglich. Linux war nicht betroffen. Die Lücke zeigt, wie schnell selbst etablierte Container-Plattformen durch kleine Konfigurationsfehler in die Defensive geraten. Administratoren sollten deshalb interne Schnitt- stellen und APIs konsequent mit Authentifizierung absichern und den Zugriff auf die Docker Engine kontrollieren.

Escapes vermeiden

Die Maßnahmen zur Absicherung von Containern lassen sich in fünf Bereiche untergliedern: Härtung der Container und Runtimes, Absicherung des Hostsystems, Einsatz von Mandatory Access Control, Sicherheit der Container-Images, sowie Laufzeitüberwachung. Für besonders kritische Umgebungen empfehlen sich darüber hinaus zusätzliche Sandbox-Technologien.

1. Container- und Runtime-Härtung

Der erste Ansatzpunkt ist die direkte Konfiguration der Container selbst. Eine der größten Gefahren geht von privilegierten Containern aus. Wer bei Docker oder Podman die Option "privileged" setzt, gibt dem Container praktisch uneingeschränkten Zugriff auf das Hostsystem. Alle Sicherheitsmechanismen wie Linux-Namespaces oder Control Groups sind damit ausgehebelt. In einer Testumgebung mag das bequem erscheinen, in Produktionsumgebungen darf dies aber niemals vorkommen.

Ein zweiter wichtiger Punkt betrifft die Linux-Capabilities. Diese Mechanismen ermöglichen es, die allumfassenden Root-Rechte in kleinere, fein abgestufte Berechtigungen aufzuteilen. Standardmäßig erhalten Container bereits einige dieser Rechte. Doch wer sich nicht aktiv darum kümmert, gibt damit oft weitreichendere Möglichkeiten frei, als für die Anwendung tatsächlich erforderlich sind. Der sicherste Weg ist, mit der Option "cap-drop=ALL" zunächst alle Rechte zu entziehen und anschließend nur die unbedingt benötigten gezielt wieder hinzuzufügen. Das verringert das Risiko einer missbräuchlichen Ausweitung der Rechte.

Ein besonders wirksamer Schutz bietet der Einsatz von Rootless Containern. Normalerweise benötigen Container Root-Rechte auf dem Host. Mit dem Rootless Mode von Docker oder der von Haus aus root-freien Architektur von Podman funktionieren Container jedoch ohne diese Rechte. In Kubernetes lassen sich über den "SecurityContext" Parameter wie "runAsUser" oder "runAsNonRoot" setzen, sodass Containerprozesse nicht als Root laufen. Ergänzend sorgen Mechanismen wie "Pod Security Admission" dafür, dass Pods nur unter Einhaltung bestimmter Sicherheitsstandards zugelassen sind. Auch Rootless-Container-Engines wie Podman oder Docker im Rootless Mode sind innerhalb von Kubernetes verwendbar, sodass es keiner Root-Rechte auf Hostebene bedarf. Das senkt das Risiko, denn selbst wenn ein Angreifer aus einem Container ausbricht, erhält er dadurch nicht automatisch volle Kontrolle über das Hostsystem.

2. Absichern des Hostsystems

Auch wenn Container sauber konfiguriert sind, bleibt das Hostsystem die zentrale Angriffsfläche. Deshalb gehören die regelmäßige Aktualisierung des Linux-Kernels und aller sicherheitsrelevanten Komponenten zu den wichtigsten Maßnahmen überhaupt. Viele Container-Escapes beruhen auf Kernelschwachstellen – wer hier aktuell bleibt, schließt damit die größten Lücken.

Darüber hinaus sollten Sie den Host so minimal wie möglich halten. Je mehr Dienste und Komponenten auf dem System laufen, desto größer ist die Angriffsfläche. Spezialisierte Betriebssysteme wie Bottlerocket [4] von Amazon, Talos Linux [5] oder Flatcar Linux [6] sind gezielt für den Betrieb von Containern entwickelt worden. Sie enthalten nur die nötigsten Komponenten und lassen sich dadurch besser absichern.

Für besonders sensible Anwendungen empfiehlt es sich außerdem, Container nicht auf gemeinsam genutzten Hosts zu betreiben. Stattdessen lassen sich dedizierte Systeme oder virtuelle Maschinen nutzen, um eine physische oder virtuelle Trennung zu schaffen. Dies verhindert, dass ein erfolgreicher Escape aus einem weniger kritischen Container auch den Zugriff auf besonders wertvolle Daten ermöglicht.

3. Mandatory Access Control einsetzen

Linux bietet mit AppArmor, SELinux und Seccomp leistungsstarke Werkzeuge, um Prozesse zusätzlich abzusichern. Wie im Abschnitt über Sicherheitsmodule als zweite Verteidigungslinie beschrieben, wirken diese Technologien als ergänzender Schutz. Selbst wenn es einem Angreifer gelingt, die Container-Isolation zu durchbrechen, stößt er auf weitere Barrieren. AppArmor und SELinux beschränken genau, auf welche Ressourcen ein Container zugreifen darf – etwa Dateien, Verzeichnisse oder Netzwerkschnittstellen. Damit verhindern Sie, dass ein erfolgreicher Angriff automatisch das gesamte System kompromittiert.

Seccomp geht einen Schritt weiter: Es ermöglicht, die Zahl der erlaubten Systemaufrufe drastisch zu reduzieren. Da viele Exploits auf gefährlichen Aufrufen wie "ptrace" oder "mount" beruhen, erhöht ein restriktives Seccomp-Profil die Sicherheit. Die Kombination dieser drei Technologien macht Container wesentlich robuster gegen Escape-Versuche.

4. Container-Images und Registries absichern

Eine weitere große Schwachstelle liegt nicht in der Technik selbst, sondern im Ursprung der Container. Wer unbedacht Images aus dem Internet herunterlädt und ausführt, setzt sich einem erheblichen Risiko aus. Angreifer können manipulierte Images mit versteckter Malware verbreiten, die beim Start sofort versucht, den Container zu kompromittieren.

Darum sollten Sie ausschließlich geprüfte und signierte Images aus vertrauenswürdigen Quellen einsetzen. Tools wie Cosign, Notary v2 oder Sigstore helfen, die Authentizität und Integrität von Images zu überprüfen.

Zudem lohnt es sich, minimale Basisimages zu verwenden. Distributionen wie Alpine, BusyBox oder Distroless enthalten nur das absolut Notwendige. Auch dadurch sinkt die Zahl potenzieller Angriffsflächen. Ein weiterer Baustein ist die Automatisierung von Schwachstellenscans. Werkzeuge wie Trivy [7], Grype [8] oder Clair [9] prüfen Container-Images auf bekannte Sicherheitslücken (CVE-Einträge) und warnen vor Risiken.

5. Laufzeitüberwachung und Anomalieerkennung

Selbst die beste Prävention ersetzt keine Überwachung. Angriffe lassen sich nie vollständig ausschließen – daher ist eine aktive Laufzeitanalyse unverzichtbar. Moderne Werkzeuge wie Falco [10], Cilium Tetragon [11] (Open Source) oder Sysdig Secure [12] (kommerzielles Produkt auf Falco-Basis) überwachen Container in Echtzeit und erkennen verdächtige Aktivitäten. Dazu gehören ungewöhnliche Systemaufrufe, unerwartete Dateioperationen oder abweichendes Netzwerkverhalten. Spezialisierte Tools wie Datadog, Dynatrace, Nagios und Zabbix integrieren sich in Kubernetes und Docker, um Metriken in Echtzeit zu verfolgen und zu alarmieren. Sammeln und analysieren Sie Audit-Logs dabei immer zentral, um Anomalien rechtzeitig zu erkennen.

Sandboxing und Isolationsverstärker

Für besonders sensible Workloads reichen Standardmaßnahmen oft nicht aus. Hier bieten sich weitere Isolationsschichten an:

- gVisor [13] von Google ist ein Userspace-Kernel, der Systemaufrufe abfängt und in einer isolierten Umgebung ausführt. Das stoppt viele Angriffe bereits auf dieser Ebene.

- Kata Containers [14] kombinieren Container-Technik mit leichtgewichtiger Virtualisierung. Jeder Container läuft dabei in einer kleinen virtuellen Maschine, was eine sehr starke Trennung gewährleistet, ohne die Effizienz vollständig zu verlieren.

- Firecracker [15], von Amazon entwickelt, setzt auf MicroVMs und eignet sich besonders für Multi-Tenant-Umgebungen, in denen Container verschiedener Kunden strikt voneinander isoliert laufen müssen.

Fazit

Ein Container Escape ist kein theoretisches Szenario mehr, sondern eine reale Bedrohung, die in den letzten Jahren mehrfach aufgetreten ist. Mit der zunehmenden Nutzung von Containern in Cloudumgebungen steigt das Risiko entsprechend. Doch durch die konsequente Kombination aus restriktiver Rechtevergabe, Hosthärtung, Sicherheitsmodulen, geprüften Images und kontinuierlicher Laufzeitüberwachung verringern Sie das Gefahrenpotenzial erheblich. Container-Sicherheit bedeutet also nicht, für sensible Workloads auf Container zu verzichten, sondern sie vielmehr bewusst und mit den richtigen Schutzmechanismen einzusetzen.

Container härten

Gut isoliert

Wie Container Anwendungen isolieren

Wie Container Anwendungen isolieren

Control Groups und Root-Rechte

Dateisysteme isolieren

Sicherheitsmodule als zweite Verteidigungslinie

Zusammenspiel der Mechanismen

Wie Container Escapes funktionieren

Vorfälle in der Praxis

Escapes vermeiden

1. Container- und Runtime-Härtung

2. Absichern des Hostsystems

3. Mandatory Access Control einsetzen

4. Container-Images und Registries absichern

5. Laufzeitüberwachung und Anomalieerkennung

Sandboxing und Isolationsverstärker

Fazit