Ein Linux-Container teilt sich einen Kernel mit allem anderen auf dem Host. Genau dieser eine geteilte Kernel ist auch der größte Teil der Angriffsfläche. In dem Moment, in dem eine Multi-Tenant-Plattform Code ausführt, dem sie nicht vollständig vertraut — Kundenfunktionen, CI-Jobs, KI-Agenten, die Tools ausführen — ist dieser geteilte Kernel kein Implementierungsdetail mehr, sondern eine Sicherheitsentscheidung.
Firecracker und gVisor sind die beiden am häufigsten eingesetzten Antworten auf diese Entscheidung. Beide schieben eine Isolationsschicht zwischen einen nicht vertrauenswürdigen Workload und den Host-Kernel, tun das aber auf grundlegend verschiedene Weise. Dieser Artikel erklärt, wie beide funktionieren, wo ihre Stärken liegen, wo nicht, und wie man in der Produktion zwischen ihnen wählt.
Das Problem: ein geteilter Kernel
Standard-Container-Runtimes — Docker, containerd, CRI-O — isolieren Prozesse mit Linux-Namespaces und cgroups und schränken Syscalls über seccomp und Capabilities ein. Für vertrauenswürdigen Code ist das eine gute Isolation. Es ist aber keine Sicherheitsgrenze, auf die man eine Multi-Tenant-Plattform setzen möchte.
Der Grund ist einfach: Jeder Container ruft direkt in denselben Host-Kernel. Der Linux-Kernel stellt rund 350 Systemaufrufe bereit, und ein einziger ausnutzbarer Fehler in einem davon kann zu einem Container-Ausbruch werden. Namespaces verringern, was ein Prozess sehen kann; sie ändern nicht, welcher Kernel seine Syscalls bearbeitet.
Die Frage für nicht vertrauenswürdige Workloads lautet also: Wie verhindern wir, dass ein kompromittierter Workload direkt den Host-Kernel erreicht? Firecracker und gVisor geben zwei verschiedene Antworten.
Wie Firecracker funktioniert
Firecracker ist ein Virtual Machine Monitor (VMM). Von AWS in Rust entwickelt, betreibt es AWS Lambda und AWS Fargate. Statt den Host-Kernel zu teilen, bootet jede Firecracker-microVM ihren eigenen Gast-Kernel auf Basis von Hardware-Virtualisierung (KVM).
Die Isolationsgrenze ist die Hardware-Virtualisierungsschicht. Ein nicht vertrauenswürdiger Workload spricht mit seinem eigenen Gast-Kernel; dieser ist durch die Virtualisierungsfunktionen der CPU vom Host getrennt. Um den Host zu erreichen, müsste ein Angreifer aus dem Gast-Kernel und aus der VM ausbrechen — eine deutlich höhere Hürde als das Ausnutzen eines einzelnen Host-Syscalls.
Firecracker bleibt schnell, weil es bewusst minimal ist:
- Ein reduziertes Gerätemodell — nur
virtio-net,virtio-block, eine serielle Konsole und ein einfacher Tastatur-Controller. Kein BIOS, kein PCI, kein USB. - Eine Bootzeit von rund 125 ms bis zum Anwendungscode.
- Ein Speicher-Overhead von etwa 5 MB pro microVM.
- Ein Firecracker-Prozess pro VM, zusätzlich abgesichert mit seccomp, Namespaces und cgroups.
Diese Kombination — eine echte VM-Grenze bei nahezu Container-Startzeit — ist der Grund, warum Firecracker zum Standard für Serverless-Plattformen wurde, die Millionen kurzlebiger, nicht vertrauenswürdiger Aufrufe ausführen.
Wie gVisor funktioniert
gVisor verfolgt den umgekehrten Ansatz: Es nutzt überhaupt keine Hardware-Virtualisierung. Von Google entwickelt und in Google Cloud Run sowie GKE Sandbox eingesetzt, schiebt gVisor einen Userspace-Kernel — eine Komponente namens runsc — zwischen Workload und Host.
Wenn ein Sandbox-Prozess einen Systemaufruf macht, erreicht dieser nie direkt den Host-Kernel. Der Aufruf wird abgefangen und vom eigenen, in Go geschriebenen Kernel von gVisor bedient, der einen großen Teil der Linux-Syscall-Oberfläche im Userspace nachbildet. Nur ein kleiner, streng kontrollierter Satz an Operationen wird an den Host weitergereicht.
Das Ergebnis ist eine drastisch kleinere Host-Angriffsfläche. Der Workload darf jeden beliebigen Syscall absetzen, spricht dabei aber mit runsc, nicht mit dem Host. Ein Fehler im emulierten Syscall betrifft die Sandbox, nicht den Host-Kernel.
Die Kompromisse unterscheiden sich von Firecracker:
- Kein KVM erforderlich, was in Umgebungen mit verschachtelter Virtualisierung zählt, in denen keine Hardware-Virtualisierung verfügbar ist (manche Cloud-VMs, manche CI-Runner).
- Syscall-Overhead: Jeder abgefangene Aufruf zahlt einen Userspace-Umweg. Syscall- und I/O-lastige Workloads spüren das am stärksten.
-
Kompatibilitätslücken: Da gVisor den Kernel nachbildet, werden einige seltenere Syscalls oder
/proc-Funktionen nicht unterstützt oder verhalten sich anders.
Firecracker vs. gVisor im direkten Vergleich
| Dimension | Firecracker (microVM) | gVisor (Userspace-Kernel) |
|---|---|---|
| Isolationsmechanismus | Hardware-Virtualisierung (KVM) | Abgefangene Syscalls im Userspace (runsc) |
| Gast-Kernel | Eigener echter Linux-Kernel | Nachgebildeter Kernel in Go |
| Benötigt KVM / Bare Metal | Ja | Nein |
| Boot / Start | ~125 ms | Schneller Prozessstart, kein VM-Boot |
| Host-Angriffsfläche | Sehr klein (VM-Grenze) | Klein (begrenzte Host-Syscalls) |
| Kompatibilität | Hoch (echter Kernel) | Gut, mit Lücken bei seltenen Syscalls |
| Ideal für | Starke Isolation, Serverless, Multi-Tenant-Codeausführung | Container-natives Sandboxing ohne KVM |
| Bekannte Nutzer | AWS Lambda, AWS Fargate | Google Cloud Run, GKE Sandbox |
Performance: Was dich wirklich kostet
Die ehrliche Zusammenfassung lautet: Keine der beiden Optionen ist kostenlos, und die Kosten zeigen sich an unterschiedlichen Stellen.
Firecracker zahlt seinen Preis bei Boot und Speicher: Man startet eine echte (wenn auch winzige) VM, also gibt es eine Kernel- und Speicheruntergrenze pro VM. Für langlaufende Dienste ist dieser Overhead vernachlässigbar; für sehr kurzlebige Sub-Sekunden-Workloads ist es die Stellschraube, die man optimiert.
gVisor zahlt seinen Preis pro Syscall. CPU-lastige Arbeit, die den Kernel selten anfasst, läuft nahezu nativ. Workloads, die den Kernel jedoch beanspruchen — viele kleine Netzwerkaufrufe, intensive Datei-I/O, häufiges fork/exec — zahlen eine messbare Abgabe, weil jeder dieser Aufrufe abgefangen wird.
Eine nützliche Faustregel:
- Rechenintensiv, syscall-arm → der Overhead von gVisor ist gering.
- I/O- oder syscall-lastig → das Modell von Firecracker gewinnt oft.
- Stärkste Isolation pro Risiko-Euro → die VM-Grenze von Firecracker ist für Compliance leichter zu begründen.
Wie man wählt
Die Entscheidung dreht sich selten darum, welche Technologie „besser“ ist. Es geht um deine Rahmenbedingungen. Hier ist das Framework, das ich verwende.
Wähle Firecracker, wenn:
- Du wirklich nicht vertrauenswürdigen, Multi-Tenant-Code ausführst (Functions-as-a-Service, von Kunden eingereichte Jobs, sandboxed KI-Tool-Ausführung).
- Du KVM bekommst (Bare Metal oder verschachtelte Virtualisierung ist verfügbar).
- Du die sauberste mögliche Isolationsgeschichte für Auditoren willst: Eine VM-Grenze ist gut verstanden.
Wähle gVisor, wenn:
- Du keine Hardware-Virtualisierung bekommst (manche Managed-Umgebungen, verschachteltes CI).
- Du container-native Ergonomie und eine OCI-Runtime (
runsc) als Drop-in unter Kubernetes willst. - Deine Workloads rechengebunden und tolerant gegenüber kleineren Syscall-Kompatibilitätslücken sind.
Bleib bei Standard-Containern + seccomp, wenn:
- Der Code vertrauenswürdig ist (deine eigenen Dienste) und Namespaces, cgroups, seccomp und ein gehärtetes Profil eine angemessene Grenze sind. Zahle keinen Isolations-Overhead, den du nicht brauchst.
Wo das in einer Sicherheitsarchitektur einzuordnen ist
microVMs und Userspace-Kernel sind eine Schicht, keine vollständige Strategie. In einem Defense-in-Depth-Design stehen sie neben, nicht anstelle von:
- Least-Privilege-IAM und kurzlebigen Credentials,
- Network Policy und Egress-Kontrolle um die Sandbox,
- seccomp und Capability-Dropping auch innerhalb der Sandbox,
- Image-Provenance und Supply-Chain-Verifizierung dessen, was überhaupt läuft.
Die Sandbox begrenzt den Schadensradius, wenn etwas in ihr kompromittiert wird. Sie macht die übrigen Kontrollen nicht überflüssig.
Fazit für 2026
Der geteilte Host-Kernel ist die stille Annahme hinter den meisten Container-Deployments — und das ist in Ordnung, bis du Code ausführst, dem du nicht vertraust. Ab diesem Punkt brauchst du eine echte Grenze.
Firecracker liefert diese Grenze über Hardware-Virtualisierung bei nahezu Container-Startzeit, weshalb es Serverless im großen Maßstab trägt. gVisor liefert eine kleinere Host-Angriffsfläche ohne KVM, weshalb es zu container-nativen Plattformen passt, die kein Bare Metal voraussetzen können.
Entscheide anhand von drei Dingen: ob du KVM bekommst, wie syscall-lastig deine Workloads sind und wie stark die Isolationsgeschichte sein muss, die deine Auditoren erwarten. Passe die Grenze an die Bedrohung an — und zahle nicht für Isolation, die deine Workloads nicht brauchen.
Ursprünglich auf meinem Blog veröffentlicht, wo ich ihn aktuell halte: Immer aktuelle Version lesen →
Ich schreibe über Platform Engineering, Google Cloud und Cloud-Security — auf Deutsch und Englisch. Mehr davon gibt es hier.
Top comments (0)