Begriff
Container Isolation
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Viele Leute denken, Container sind wie "kleine virtuelle Server". Das stimmt nicht. Container sind Prozesse (wie Word oder Chrome) auf dem gleichen Betriebssystem wie alle anderen. Aber sie tragen eine "VR-Brille" (Namespaces) und Fesseln (cgroups). Die Isolation sorgt dafür, dass:
- Der Container denkt, er wäre allein auf der Welt (sieht keine anderen Prozesse).
- Er nicht auf Dateien außerhalb seines Ordners zugreifen kann.
- Er den Server nicht überlasten kann. Aber: Wenn der Linux-Kernel abstürzt (Kernel Panic), sterben alle Container. Bei einer VM (Virtual Machine) stirbt nur die eine VM. Container sind also "weniger isoliert" als VMs.
Merksatz: Die Trennung von Prozessen in Containern vom Host-System und anderen Containern durch Kernel-Features (Namespaces, cgroups), um Sicherheit und Ressourcen-Unabhängigkeit zu gewährleisten (Shared Kernel Architecture).
Standardmäßig ist Docker "ziemlich" sicher. Aber für echte Isolation (Multi-Tenant):
- User: Root vermeiden! Starte Container nie als
root(USER 1000im Dockerfile). - Read-Only Root FS: Verhindere, dass Malware Dateien ändert (
--read-only). - Capabilities droppen: Der Container braucht kein
NET_ADMIN(Netzwerk ändern). Nimm ihm die Rechte weg (--cap-drop ALL).
Praxisroutine
In der Praxis lernst du Container Isolation, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.
Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.
1. Die Illusion (Namespaces)
Der Kernel lügt den Prozess an.
- PID Namespace: Prozess 12345 auf dem Host sieht sich selbst als PID 1 im Container.
- Mount Namespace: Der Container sieht
/als sein Root, obwohl es auf dem Host/var/lib/docker/...ist. - Network Namespace: Eigener IP-Stack (
lo,eth0). Aber syscalls gehen direkt an den Host-Kernel! Es gibt keine "Hypervisor-Schicht".
2. Container Breakouts (Escape)
Wenn ich im Container Root bin und eine Lücke im Kernel finde (z. B. "Dirty Cow"), kann ich ausbrechen. Dann bin ich Root auf dem Host-Server. Game Over. Deshalb nutzt Google gVisor oder Kata Containers. Das sind "Micro-VMs", die jeden Container in eine echte kleine VM packen. Der Kernel wird nicht geteilt. Maximale Isolation auf Kosten von Performance.
3. Seccomp & AppArmor
Du kannst dem Kernel sagen: "Dieser Container darf nur read(), write() und exit() aufrufen. Wenn er reboot() ruft -> KILL."
Das ist Seccomp (Secure Computing Mode).
Docker hat ein Default-Profile, das gefährliche Syscalls blockiert.
AppArmor/SELinux legen noch eine Schicht Mandatory Access Control (MAC) oben drauf ("Darf Nginx auf /etc/passwd zugreifen? Nein, auch nicht als Root.").
cgroups v1 vs. cgroups v2 (Control Groups)
Die Einschränkung von Ressourcen (CPU, RAM, Block I/O) obliegt den cgroups (Control Groups). Lange Zeit war cgroups v1 der Standard. Es war hochkomplex strukturiert; es erlaubte z. B., dass ein Prozess in Bezug auf CPU zu Gruppe A gehörte, in Bezug auf Speicher aber zu Gruppe B. Dies führte zu inkonsistentem Memory-Management (insbesondere OOMKills bei Swap), was den Kernel überforderte. Der moderne Standard (fast überall Default in Linux-Kerneln > 4.15) ist cgroups v2. V2 erzwingt eine strikte, einheitliche Hierarchie (Tree-Struktur). Ein Container ist exakt an einen Knotenpunkt im Baum für alle Ressourcentypen gebunden. Dies verbessert die Controller-Synchronisation im Kernel, erlaubt Container-Aware Speicher-Accounting und verhindert Freezes unter extremen Page-Cache Lasten.
Kata Containers & Firecracker (The MicroVM Pivot)
"Shared Kernel" bedeutet: Findet ein Hacker eine Privilege-Escalation im Linux-Socket oder Treiber-Subsystem, gehört ihm die Host-Machine und damit alle Container anderer Mieter. In Serverless-Umgebungen (AWS Fargate, Google Cloud Run) können Cloud-Anbieter diesen Multi-Tenant-Risk nicht eingehen. Sie verwerfen reine Linux Container-Namespaces zugunsten echter MicroVM-Kapselung wie AWS Firecracker oder den OS-Katalysator Kata Containers. Diese Systeme starten für jeden einzelnen Container eine stripped-down virtuelle Maschine. Der Hypervisor generiert echte PCI-Busse und Block-Devices pro KVM-Instanz. Da diese VMs einen extrem minimalen Footprint (Start in unter 50 Millisekunden) haben, verhalten sie sich auf DevOps-Automatisierungsebene identisch zu Containern, liefern aber hypervisor-backed Hardcore-Isolation.
eBPF (Cilium & Tetragon SecOps)
Da der Linux-Kernel den Flaschenhals und Single-Point-of-Failure für Isolation bildet, geht die moderne Sicherheit zunehmend in Richtung In-Kernel-Beobachtung mittels eBPF (Extended Berkeley Packet Filter).
Tools wie Tetragon überwachen alle Syscalls (z.B. execve, openat), die ein Container auf Kernel-Ebene vornimmt.
Wenn ein als Nginx deklarierter Container plötzlich versucht, ein Socket für eine unbekannte TCP-Verschlüsselung (crypt) zu registrieren, greift eBPF nicht im Userspace ein, sondern klemmt den Syscall hart auf unterster Kernel-Ebene ab, bevor überhaupt Memory allokiert wurde. Dies liefert quasi-Zero-Trust Echtzeit-Isolation, ohne Code rekompilieren zu müssen.
Quick-Check
Sind Container so sicher wie VMs?
Nein. "Container don't contain". Der Shared Kernel ist ein Single Point of Failure. Für feindliche Multi-Tenancy (z. B. "Lasse Code von Fremden laufen") braucht man VMs (Firecracker/Kata).Was ist "Rootless Docker"?
Der Docker Daemon selbst läuft als normaler User (nicht Root). Selbst wenn man ausbricht, ist man auf dem Host nur ein User ohne Rechte. Großer Sicherheitsgewinn.Privileged Container?
--privileged. Gibt dem Container alle Capabilities und Zugriff auf alle Devices. Das hebt die Isolation effektiv auf. Mache das nie, außer du weißt exakt warum (z. B. Docker-in-Docker).