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.
Häufig gestellte Fragen#
Ist gVisor eine virtuelle Maschine?
Nein. gVisor nutzt keine Hardware-Virtualisierung. Es betreibt einen Userspace-Kernel (runsc), der die Systemaufrufe des Workloads abfängt und selbst bedient und nur einen kleinen Teil an den Host weiterleitet.
Ist Firecracker langsamer als ein Container? Im Dauerbetrieb nein. Eine laufende Firecracker-microVM erreicht nahezu Container-Performance. Der sichtbare Preis ist der Start (~125 ms) und eine kleine Speicheruntergrenze pro VM, was nur bei sehr kurzlebigen Workloads zählt.
Kann ich Firecracker oder gVisor unter Kubernetes betreiben?
Ja. gVisor liefert eine OCI-Runtime (runsc), nutzbar als RuntimeClass. Firecracker integriert sich über Projekte wie Kata Containers und firecracker-containerd zu einer CRI-kompatiblen Runtime.
Was ist sicherer, Firecracker oder gVisor? Beide reduzieren die Host-Angriffsfläche deutlich. Die Hardware-Virtualisierungsgrenze von Firecracker ist für Compliance meist leichter zu begründen, während der Userspace-Kernel von gVisor die Host-Syscall-Oberfläche ohne KVM verkleinert. Die richtige Antwort hängt von deinem Bedrohungsmodell und deiner Infrastruktur ab.
Brauche ich eines von beiden, wenn mein Code vertrauenswürdig ist? In der Regel nicht. Für eigene, vertrauenswürdige Workloads reichen Namespaces plus ein starkes seccomp-Profil meist aus. Reserviere microVMs und gVisor für Code, dem du nicht vollständig vertraust.
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.