Von Kernel-Isolation zu microVM-Sandboxes: Wie Docker Isolation neu definiert

Docker hat Container nicht nur populär gemacht. Es hat grundlegend verändert, wie wir Software bauen, ausliefern und betreiben, und das seit mehr als zehn Jahren. Jetzt passiert etwas, das ähnlich wichtig ist.

Workloads verändern sich. Vertrauensgrenzen werden komplizierter. Und Docker schiebt Container und Isolation ein zweites Mal in eine neue Ära: von der Shared-Kernel-Isolation klassischer Container hin zu Sandboxes auf Basis von microVMs.

Das ist kein Ersatz für Docker oder Container. Es ist eine Weiterentwicklung dessen, was „isolierte Workloads ausführen“ überhaupt bedeutet. In diesem Beitrag gehen wir auf eine Reise: durch die Kernel-Mechanismen, die Container möglich machen, hinein in Docker Sandboxes auf microVM-Basis, und zu der Frage, worin sich ein Container und eine microVM technisch fundamental unterscheiden.

Das Fundament: Container waren immer eine Kernel-Geschichte

Vor Docker gab es keine „Container-Plattform“. Es gab „nur“ Primitive im Linux-Kernel. Die wichtigsten Bausteine:

Mechanismus	Aufgabe
Namespaces	isolieren, was ein Prozess sieht
cgroups	begrenzen, was ein Prozess verbrauchen darf
Capabilities	zerlegen Root-Rechte in kleine Einheiten
LSMs (SELinux, AppArmor)	setzen Zugriffsrichtlinien durch
seccomp	filtern Systemaufrufe

Diese Funktionen kamen nicht auf einmal. Sie wurden über Jahre Stück für Stück in den Kernel eingebaut und ergaben irgendwann einen Werkzeugkasten für Virtualisierung auf Betriebssystemebene.

Auf unterster Ebene hat das alles verändert. Statt einer globalen Systemsicht für alle Prozesse konnte Linux jetzt mehrere isolierte Sichten auf denselben Kernel anbieten, je Prozessgruppe. Ein Container ist technisch gesehen nur ein Prozess mit eigenem PID-Baum, eigenem Netzwerk-Stack, eigener Mount-Tabelle und begrenzten Ressourcen. Aber, und das ist der entscheidende Punkt:

Er läuft auf demselben Kernel wie alles andere.

Vor Docker: LXC und die ersten Container

Linux Containers (LXC) war das erste größere System, das diese Primitive zu etwas Benutzbarem zusammensetzte. LXC bewies eine zentrale Idee: Man braucht keinen Hypervisor, um Workloads zu isolieren. Der Kernel kann das selbst.

Aber LXC blieb low-level und systemorientiert. Es löste weder Packaging noch Distribution, weder Reproduzierbarkeit noch, am wichtigsten, den Workflow von Entwicklern. Genau da hat Docker alles verändert.

Dockers Durchbruch: das Container-Modell standardisieren

Meine erste praktische Begegnung mit Docker hatte ich 2017 auf der DockerCon in Austin, Texas. Ich hatte damals keine Ahnung, was Container sind oder wie sie unter der Haube funktionieren. Nach vielen Jahren täglicher Arbeit mit Containern, inzwischen als Docker Captain, kann ich sagen: Docker hat Container zu einem einfachen, mächtigen und breit akzeptierten Standard gemacht, der die Art verändert hat, wie Software gebaut und ausgeliefert wird.

Die eigentlichen Innovationen waren:

• Layered Images auf Basis von Copy-on-Write-Dateisystemen wie OverlayFS
• Deklarative Builds per Dockerfile
• Registries als Distributionsmodell
• Eine konsistente CLI und UX
• Ein portables Runtime-Modell

Unter der Haube nutzte Docker anfangs LXC. Mit Docker 0.9 im März 2014 kam libcontainer, und die Container-Ausführung wanderte vollständig in Dockers eigenen Stack. Im Juni 2015 gründete Docker zusammen mit anderen die Open Container Initiative und spendete libcontainer als Basis für runc. Mit Docker 1.11 im April 2016 wurde containerd als eigenständige Runtime-Schicht herausgelöst. Daraus entstand die Architektur, die bis heute gilt:

Docker CLI
   |
   v
Docker Engine (dockerd)
   |
   v
containerd
   |
   v
OCI Runtime (runc)
   |
   v
Linux-Kernel (Namespaces, cgroups, seccomp, ...)

Diese Trennung war entscheidend. Sie machte Docker zu einer Schnittstellenschicht, nicht nur zu einer Runtime. Und genau diese Entscheidung aus den frühen Jahren ist es, die Docker Sandboxes heute möglich macht.

Was „Docker-Isolation“ tatsächlich bedeutet

Ein klassischer Docker-Container ist ein Linux-Prozess in einer sorgfältig konstruierten Isolationsgrenze. Beim Start legt die Runtime genau die Mechanismen aus der Tabelle oben übereinander, hängt ein OverlayFS als Dateisystem ein und startet den Init-Prozess des Containers. Das ist eine hochentwickelte Isolation, aber sie erzeugt keinen eigenen Kernel. Deshalb gibt es auf Docker Desktop für Mac und Windows eine Linux-VM, die den Linux-Kernel bereitstellt, ohne den Linux-Container nicht laufen können. Wie diese VM entsteht, habe ich im Beitrag zu Docker VMM beschrieben.

Der Kompromiss, mit dem Container gewonnen haben

Dieses Shared-Kernel-Modell ist genau der Grund, warum Container so erfolgreich sind:

• Schnell: Start in Millisekunden
• Leichtgewichtig: kein Gast-Betriebssystem, keine echte VM
• Dicht: viele Container pro Host
• Effizient: minimaler Overhead

Docker hat das genutzt, um Microservice-Architekturen, CI/CD-Pipelines, reproduzierbare Entwicklungsumgebungen und Cloud-native Plattformen zu ermöglichen. Ein gewaltiger Sprung. Aber diese Effizienz hat eine Decke.

Selbst mit Namespaces, cgroups, seccomp, Capabilities und LSMs gilt: Ein Container spricht per Syscall direkt mit dem Host-Kernel. In Klartext heißt das: Eine Kernel-Schwachstelle betrifft alle Container. Ein Container-Ausbruch zielt auf Host-Kernel und Runtime. Und die Isolation ist policy-basiert, nicht hardware-erzwungen.

Für vertrauenswürdige Workloads ist das oft in Ordnung. Für nicht vertrauenswürdige oder mandantenfähige Workloads reicht es nicht immer. Und wenn wir moderne KI-Systeme dazunehmen, die vollständig fremden Code ausführen, ist dieses Isolationsniveau ein No-Go.

Der Wandel: von Containern zu Sandboxes

Plattformen haben sich weiterentwickelt, und neue Workload-Typen sind entstanden:

• Serverless Functions
• CI-Runner, die beliebigen Code ausführen
• Browserbasierte Entwicklungsumgebungen
• Plugin-Ökosysteme
• Mandantenfähige SaaS-Control-Planes
• KI-Agenten, die fremden Code ausführen

Die Frage hat sich verschoben. Aus „Wie paketiere ich meine Anwendung?“ wurde „Wie führe ich sicher Code aus, dem ich nicht vollständig vertraue oder den ich nicht einmal selbst geschrieben habe?“ KI-Agenten ziehen gerade die Aufmerksamkeit auf sich, aber das Muster ist überall dasselbe: Workloads ausführen, deren Vertrauensniveau niedriger ist als das des Hosts, ohne das System selbst zu gefährden. Genau dort entwickelt Docker das Modell weiter.

Docker Sandboxes

Docker Sandboxes sind der logische nächste Schritt. Docker beschreibt das Produkt als „disposable, isolated sandboxes for AI agents like Claude Code, Copilot CLI, Codex, OpenCode, and Kiro that need safe, unattended execution“. Jeder Agent läuft in einer eigenen microVM, in die nur das Projektverzeichnis eingehängt wird. Darin darf er alles: Pakete installieren, Konfigurationen ändern, Dienste starten. Der Host bleibt unberührt.

Das Produkt ist frei verfügbar, heißt auf der Kommandozeile sbx und braucht kein Docker Desktop. Die microVM-Variante wurde am 30. Januar 2026 für macOS und Windows vorgestellt, inzwischen gibt es laut Installationsanleitung auch Linux-Pakete. Sie bekommen weiterhin, was Sie kennen: Docker-Images, Dockerfiles, vertraute Workflows und Tooling. Aber statt direkt auf dem Host-Kernel laufen Container und andere Workloads wie KI-Agenten in stark isolierten Sandboxes, angetrieben von microVMs. Das ist keine neue Abstraktion. Es ist eine neue Ausführungsschicht.

microVMs: Hardware-Isolation bei fast Container-Geschwindigkeit

Eine microVM ist eine zweckgebundene virtuelle Maschine. Sie ist minimal, startet in Millisekunden bis wenigen Sekunden, isoliert auf Hardware-Ebene und emuliert nur, was der Gast wirklich braucht. In einem Satz:

Eine microVM ist eine minimale virtuelle Maschine, die von einem Virtual Machine Monitor (VMM) erzeugt und verwaltet wird und dafür den Hypervisor des Host-Betriebssystems nutzt.

Dieser Hypervisor ist auf Linux KVM, auf macOS Apples Hypervisor.framework und auf Windows die Windows Hypervisor Platform. Was ein VMM darüber leistet, von virtuellen Geräten bis zum Lebenszyklus, habe ich im Beitrag zu Docker VMM beschrieben.

Und hier kommt der Punkt, der Docker von anderen Anbietern unterscheidet: Docker hat seinen eigenen VMM gebaut. Statt eine fremde Implementierung einzubinden, läuft unter Docker Sandboxes dieselbe Virtualisierungsschicht, die Docker mit Docker VMM auch unter Docker Desktop einsetzt und die für genau einen Gast optimiert ist: einen Linux-Kernel, der Container ausführt. Docker nennt Sandboxes im VMM-Beitrag ausdrücklich als das erste Produkt, das auf diesem Fundament sitzt.

Technisch bedeutet das für jede Sandbox:

• Eigener Gast-Kernel. Die microVM bootet einen eigenen Linux-Kernel. Syscalls des Agenten enden dort, nicht auf dem Host.
• Minimale virtuelle Hardware. Geräte kommen über virtio, das Projektverzeichnis über virtiofs mit aktiviertem Caching. Kein BIOS, keine Grafikkarte, keine Legacy-Geräte.
• Eigene Docker Engine. In der Sandbox läuft ein vollständiger Docker-Daemon mit eigenem Image-Cache. Der Agent kann Container bauen und starten, ohne je den Docker-Socket des Hosts zu sehen.
• Eigener Speicherhaushalt. Standardmäßig bekommt eine Sandbox die Hälfte des Host-Arbeitsspeichers, einstellbar per Flag.

Was sich technisch ändert

Wir haben oben die klassische Architektur skizziert. So sieht die microVM-basierte Variante aus:

[ Anwendung / KI-Agent ]
          |
          v
[ Container ]  (optional, mit eigener Docker Engine in der Sandbox)
          |
          v
[ microVM mit eigenem Gast-Kernel ]
          |
          v
[ Docker VMM ]
          |
          v
[ Host-Hypervisor: KVM / Hypervisor.framework / WHP ]
          |
          v
[ Host-Kernel ]
          |
          v
[ Hardware ]

Das führt eine neue Grenze ein. Die Anwendung spricht nicht mehr direkt mit dem Host-Kernel. Ihre Syscalls gehen an den Gast-Kernel, und ein Kernel-Exploit bleibt in der Sandbox. Das ist keine schrittweise Härtung, sondern eine andere Klasse von Isolation: Workloads sind an einer Virtualisierungsgrenze getrennt, nicht vertrauenswürdiger Code kann nebeneinander laufen.

Das Sicherheitsmodell im Detail

Die Security-Doku beschreibt fünf Isolationsebenen, und die lohnen einen genauen Blick, weil sie zeigen, dass die microVM allein nicht die ganze Geschichte ist.

Hypervisor-Isolation. „The primary trust boundary is the microVM. The agent has full control inside the VM, including sudo access.“ Der Agent darf drinnen Root sein, weil die VM-Grenze verhindert, dass er nach draußen kommt.

Netzwerk-Isolation. Aller ausgehende TCP-Verkehr läuft über einen Proxy auf dem Host und unterliegt einer Deny-by-default-Policy. Direktes UDP und ICMP nach außen sind blockiert. HTTP und HTTPS gehen durch einen Forward-Proxy, anderer TCP-Verkehr wird transparent weitergeleitet, beides mit Zugriffsregeln. Wer meinen Beitrag zum DseWiki-Vorfall gelesen hat, weiß, warum genau diese Egress-Kontrolle der wichtigste Teil ist.

Docker-Engine-Isolation. Jede Sandbox hat ihre eigene Engine, ohne Pfad zum Host-Daemon.

Workspace-Isolation. Drei Modi: Direct Mount (Projektverzeichnis lesend und schreibend, Pfade wie auf dem Host), Clone (Original schreibgeschützt unter /run/sandbox/source, der Agent arbeitet auf einer privaten Kopie) und Mountless (alles bleibt in der Sandbox).

Credential-Isolation. Das ist mein Lieblingsdetail: „API keys are injected into HTTP headers by the host-side proxy. Credential values never enter the VM.“ Der Agent sieht seinen eigenen API-Schlüssel nie. Ein kompromittierter Agent kann ihn also auch nicht exfiltrieren.

Dazu kommen Sandbox Kits: YAML-Dateien, die Tools, Umgebungsvariablen, erlaubte Domains, mitgelieferte Dateien und Startbefehle deklarieren, und die per --kit beim Anlegen einer Sandbox angewendet werden. Für Teams ist das die Stelle, an der aus „jeder baut sich seine Sandbox“ ein reproduzierbarer Standard wird.

Was die microVM nicht löst

Docker ist in der Doku erfreulich ehrlich über die Grenzen, und ich wiederhole sie hier, weil sie in der Praxis den Unterschied machen.

• Implizite Ausführung im Direct-Mount-Modus. Der Agent bearbeitet dieselben Dateien, die Sie auf dem Host sehen. Dazu gehören Git-Hooks, CI-Konfigurationen und IDE-Task-Definitionen, die beim nächsten normalen Arbeiten auf dem Host ausgeführt werden. Die Doku sagt es klar: Änderungen prüfen, bevor man geänderten Code ausführt.
• Breite Standard-Allowlists. Einträge wie *.googleapis.com decken weit mehr Dienste ab als nur KI-APIs. Wer es ernst meint, schreibt seine eigene Policy.
• Geteilter Skills-Store. Agent-Skills sind über Sandboxes hinweg lesend und schreibend gemountet. Eine Sandbox kann Anweisungen verändern, die ein Agent später in einer anderen Sandbox nutzt.
• Lokale MCP-Server per stdio laufen außerhalb der VM, mit Host-Rechten. Die Sandbox schützt nicht, was sie nicht enthält.

Keiner dieser Punkte ist ein Fehler im Konzept. Sie zeigen nur, dass Isolation ein Systemthema ist: microVM, Netzwerk-Policy, Workspace-Modus und Tool-Anbindung müssen zusammenpassen.

Das neue Denkmodell

Die frühe Trennung in OCI, containerd und austauschbare Runtimes zahlt sich hier aus, und mit dem eigenen VMM kontrolliert Docker jetzt jede Schicht vom Dockerfile bis zur virtuellen Hardware. Docker ist nicht mehr nur „das Ding, das Container ausführt“. Es wird zur Plattform, die definiert, wie Workloads paketiert und sicher ausgeführt werden. Container sind damit nicht mehr an ein einziges Isolationsmodell gebunden:

Docker   = Packaging + Workflow
Runtime  = wählbare Isolationsgrenze

Sie können wählen zwischen klassischen Containern mit runc, Runtimes mit User-Space-Kernel wie gVisor, VM-basierten Container-Runtimes wie Kata Containers und jetzt microVM-basierten Docker Sandboxes mit Dockers eigenem VMM. Docker Sandboxes machen daraus eine integrierte Erfahrung erster Klasse.

In der Praxis: eine Sandbox in drei Befehlen

Voraussetzungen laut Doku: macOS 14 oder neuer auf Apple Silicon, Windows 11 mit aktivierter Windows Hypervisor Platform, oder Ubuntu 24.04 mit KVM und Mitgliedschaft in der Gruppe kvm.

# macOS
brew trust docker/tap && brew install docker/tap/sbx

# Windows
winget install -h Docker.sbx

# Ubuntu
curl -fsSL https://get.docker.com | sudo SBX=1 sh

Dann im Projektverzeichnis:

sbx run claude

Das lädt das Image des Agenten, startet eine microVM, die nach dem Verzeichnis benannt ist, hängt das Verzeichnis ein und startet Claude Code ohne Rückfragen, weil die Sandbox die Rückfragen überflüssig macht. Stoppen und Neustarten behält installierte Pakete und Images, sbx rm löscht die Sandbox samt VM.

Aus meiner Erfahrung zwei Hinweise: Der Clone-Modus ist für die ersten Experimente die bessere Wahl, weil der Agent dann nicht in Ihrem echten Arbeitsverzeichnis herumschreibt. Und legen Sie die Netzwerk-Policy vor dem ersten Lauf fest, nicht danach.

Fazit: die Evolution der Isolation

Docker hat damit angefangen, Container benutzbar zu machen. Jetzt macht es sie standardmäßig sicherer. Die Reise sieht so aus:

1. Linux-Kernel-Primitive (Namespaces, cgroups)
2. LXC (frühe Container)
3. Docker (Standardisierung und UX)
4. OCI und containerd (modulare Runtime-Architektur)
5. Sandboxed Runtimes
6. microVM-basierte Docker Sandboxes mit eigenem VMM

Das Ergebnis: Wir behalten alles, was Docker zum Werkzeug der Wahl gemacht hat, und heben das Isolationsmodell auf das Niveau, das moderne Sicherheitsrealitäten verlangen. Das ist keine inkrementelle Verbesserung. Es ist die nächste Phase der Container-Evolution.

Weiterlesen

• Docker Sandboxes: Dokumentation mit Architektur, Sicherheitsmodell, Installation und CLI-Referenz
• Ankündigung der microVM-Isolation (Docker Blog, 30. Januar 2026) und Produktseite
• Docker AI Governance für zentrale Netzwerk- und Dateisystem-Policies
• Sandbox-Umgebungen in der Claude-Code-Doku
• Docker VMM Public Beta und mein Beitrag dazu
• KI Horror Stories #1: was passiert, wenn Agenten ohne diese Grenzen laufen
• Docker Engine Security, gVisor, Kata Containers