„Lass es in einer Sandbox laufen“ klingt nach einer einzigen Anweisung. In der Praxis sind damit vier verbreitete Grenzen gemeint, und sie stoppen sehr Unterschiedliches. Die falsche Wahl lässt Sie entweder ungeschützt oder macht jeden Lauf langsamer und teurer als nötig.
Dieser Vergleich geht davon aus, dass der Code wirklich nicht vertrauenswürdig ist: von einem Sprachmodell geschrieben, von einem Nutzer eingereicht oder in einem Pull Request von jemandem, den Sie nicht kennen. Selbst geschriebener Code hat andere Bedürfnisse.
Was schiefgehen kann
Bevor wir Grenzen vergleichen, lohnt es sich zu benennen, wofür sie da sind. Nicht vertrauenswürdiger Code kann:
- Lesen, was er nicht soll: Umgebungsvariablen, SSH-Schlüssel, Dateien im Home-Verzeichnis, Metadaten-Endpunkte der Cloud.
- Ressourcen erschöpfen: endlos laufen, forken, bis die Maschine steht, die Festplatte füllen.
- Das Netzwerk missbrauchen: andere Hosts scannen, Spam senden, Kryptowährung minen, Ihre internen Dienste aufrufen.
- Sich festsetzen: einen Cron-Job oder Dienst installieren, der die Aufgabe überlebt.
- Ausbrechen: einen Bug in der Schicht darunter nutzen, um Code auf dem Host selbst auszuführen.
Jede Stufe unten deckt einiges davon ab, anderes nicht.
Stufe 1: ein Prozess
Die einfachste Sandbox ist ein Kindprozess: subprocess.run mit Timeout, vielleicht unter einem eigenen Benutzer, mit Ressourcenlimits und einem seccomp-Filter, wenn man gründlich ist.
Stoppt: endlose Laufzeit (der Timeout), einen Teil der Ressourcenerschöpfung (Limits), einige gefährliche Systemaufrufe (seccomp). Stoppt nicht: das Lesen von allem, was dieser Benutzer lesen kann, Netzwerkzugriff, Festsetzen über alles, wohin der Benutzer schreiben kann, und jeden Kernel-Bug. Typisches Versagen: Der Code liest eine Datei, von der man vergessen hatte, dass sie lesbar ist, oder ein „eingeschränkter“ Sprachinterpreter hat doch eine Hintertür. Die Geschichte ist voll von Sandboxes innerhalb einer Sprache, die nicht gehalten haben.
Die Startzeit ist praktisch null. Gut für eigenen Code; keine Grenze für fremden.
Stufe 2: ein Container
Namespaces geben dem Code eine eigene Sicht auf Dateien, Prozesse und Netzwerk; cgroups begrenzen CPU und Speicher; entzogene Capabilities und seccomp engen ein, was er vom Kernel verlangen kann.
Stoppt: das Lesen von Host-Dateien (sofern nicht eingebunden), das Sehen anderer Prozesse, unbegrenzte Ressourcennutzung, einen Großteil des Festsetzungsproblems, wenn der Container weggeworfen wird. Stoppt nicht: einen Bug im geteilten Host-Kernel. Jeder Container auf der Maschine spricht mit demselben Kernel, also ist eine erreichbare Kernel-Schwachstelle ein Ausgang. Typisches Versagen: Konfiguration statt exotischer Exploits. Ein privilegierter Container, der Socket der Container-Runtime ins Innere eingebunden, Host-Netzwerk „nur zum Debuggen“ eingeschaltet. Jedes davon entfernt still die Grenze.
Die Startzeit liegt bei Millisekunden. Es gibt gehärtete Varianten, darunter Kernel im Userspace, die Systemaufrufe abfangen, bevor sie den Host erreichen, auf Kosten von Tempo und Kompatibilität. Für Code von Menschen, denen Sie vertrauen, ist ein gut konfigurierter Container ein vernünftiger Standard.
Stufe 3: eine microVM
Eine microVM betreibt ihren eigenen Kernel unter einem Hypervisor, wie eine vollständige VM, aber nahezu ohne emulierte Hardware. Das bekannteste Beispiel ist Firecracker.
Stoppt: alles, was ein Container stoppt, plus das Problem des geteilten Kernels. Um den Host zu erreichen, muss Code den Hypervisor oder eines von wenigen virtuellen Geräten brechen, eine viel kleinere Fläche als die Systemaufruf-Schnittstelle eines Kernels. Stoppt nicht: Missbrauch dessen, was Sie ihr mitgeben. Offener ausgehender Traffic lässt sich weiterhin missbrauchen; eingeschleuste Geheimnisse können weiterhin abfließen. Typisches Versagen: Richtlinien, nicht Isolation. Jemand reicht ein Produktions-Token weiter, „damit die Tests laufen“, oder lässt ausgehenden Traffic unbeschränkt, wo er nicht gebraucht wird.
Die Startzeit liegt zwischen Sekundenbruchteilen und etwa einer Sekunde, mit ein paar Megabyte Overhead. Das ist schnell genug, um pro Aufgabe eine anzulegen und danach zu löschen, was nebenbei das Festsetzen löst: Es gibt nichts mehr, wohin man zurückkehren könnte.
Stufe 4: eine vollständige virtuelle Maschine
Eine normale VM oder ein VPS hat dieselbe Art von Grenze wie eine microVM: Hardware-Virtualisierung und einen Hypervisor. Der Unterschied liegt in allem drumherum: vollständiges Gerätemodell, ein ganzes Betriebssystem, auf Wunsch eine öffentliche IP und ein Lebenszyklus in Tagen oder Monaten.
Stoppt: dieselben Problemklassen wie eine microVM, mit etwas größerer Angriffsfläche, weil mehr Hardware emuliert wird. Stoppt nicht: Missbrauch ihrer eigenen Netzwerkidentität. Eine VM mit öffentlicher IP, auf der missbräuchlicher Code läuft, bringt ihre IP auf Blocklisten, was zählt, wenn dieselbe IP Ihre E-Mails versendet. (Wenn das schon passiert ist: was tun, wenn Ihre IP auf einer Blocklist steht.) Typisches Versagen: Sie lebt zu lange. Eine für ein Experiment angelegte VM sammelt Zugangsdaten und Zustand und wird langsam selbst zu der vertrauenswürdigen Maschine, die sie schützen sollte.
Die Startzeit liegt bei Dutzenden Sekunden bis Minuten, abgerechnet wird meist monatlich. Das ist die richtige Form für einen langlebigen Dienst mit eingehenden Ports und die falsche für einen 20-Sekunden-Codelauf.
Der Vergleich
| Prozess | Container | MicroVM | Vollständige VM | |
|---|---|---|---|---|
| Eigener Kernel | nein | nein | ja | ja |
| Hauptgrenze | Benutzerrechte | Namespaces + geteilter Kernel | Hypervisor, winziges Gerätemodell | Hypervisor, vollständiges Gerätemodell |
| Startzeit | ~0 | ms | ~0.1–1 s | 10 s – Minuten |
| Overhead | keiner | gering | ein paar MiB | Dutzende–Hunderte MiB |
| Pro Aufgabe wegwerfen | leicht | leicht | leicht | langsam, teuer |
| Eingehende Ports / öffentliche IP | die des Hosts | die des Hosts | meist keine | ja |
Die Wahl
- Code, den Sie oder Ihr Team geschrieben haben: Ein Prozess oder Container genügt.
- CI für eigene Branches: ein Container auf Ihrem Runner.
- Agenten-Code, Nutzer-Einreichungen, externe Pull Requests: eine microVM pro Aufgabe, danach gelöscht.
- Ein nicht vertrauenswürdiger Dienst, der Verbindungen annehmen oder wochenlang laufen muss: eine eigene VM mit eigener IP, fern von allem, was Ihre Zugangsdaten hält oder Ihre E-Mails versendet.
Was immer Sie wählen, zwei Regeln gelten obendrauf: Legen Sie nichts hinein, was Sie dem Autor des Codes nicht geben würden, und entscheiden Sie bewusst, was das Netzwerk darf.
Wo unsere Produkte stehen
Für Stufe 3 betreiben wir Code-Sandboxes: Firecracker-microVMs, die in etwa einer Sekunde starten, mit ausgehendem Internet, ohne eingehende Ports und mit sekundengenauer Abrechnung. Sie zielen genau auf den dritten Punkt oben; wie man begrenzt, was ein Agent damit tun darf, beschreibt MCP-Schutzmaßnahmen. Für Stufe 4 gibt ein VPS wie der Tarif AI agent Ihnen eine ganze Maschine pro Monat. Die durchgerechneten Beispiele in Sandbox für KI-Agenten zeigen das microVM-Muster von Anfang bis Ende, und was KI-Agenten wirklich von Infrastruktur brauchen betrachtet Isolation als eine von mehreren Anforderungen.
Kommentare
Noch keine Kommentare. Sei der Erste.