Container- versus microVM-isolatie: 4 niveaus vergeleken, van subproces tot volledige VM

„Draai het in een sandbox” klinkt als één instructie. In de praktijk bedoelen mensen er vier gangbare grenzen mee, en die houden heel verschillende dingen tegen. De verkeerde kiezen laat je onbeschermd of maakt elke run trager en duurder dan nodig.

Deze vergelijking gaat ervan uit dat de code echt onbetrouwbaar is: geschreven door een taalmodel, ingestuurd door een gebruiker of binnengekomen in een pull request van iemand die je niet kent. Code die je zelf schreef, heeft andere behoeften.

Wat er mis kan gaan

Voordat we grenzen vergelijken, helpt het te benoemen waarvoor ze dienen. Onbetrouwbare code kan:

1. Lezen wat niet mag: omgevingsvariabelen, SSH-sleutels, bestanden in je thuismap, metadata-endpoints van de cloud.
2. Resources uitputten: eindeloos lussen, forken tot de machine vastloopt, de schijf vullen.
3. Het netwerk misbruiken: andere hosts scannen, spam versturen, cryptovaluta minen, je interne diensten aanroepen.
4. Zich nestelen: een cronjob of dienst installeren die de taak overleeft.
5. Ontsnappen: een bug in de laag eronder gebruiken om code op de host zelf uit te voeren.

Elk niveau hieronder vangt een deel daarvan op, niet alles.

Niveau 1: een proces

De eenvoudigste sandbox is een kindproces: subprocess.run met een time-out, misschien onder een eigen gebruiker, met resourcelimieten en een seccomp-filter als je grondig bent.

Houdt tegen: eindeloze uitvoering (de time-out), een deel van resource-uitputting (limieten), sommige gevaarlijke systeemaanroepen (seccomp). Houdt niet tegen: het lezen van alles wat die gebruiker kan lezen, netwerktoegang, nestelen via alles waar de gebruiker naar kan schrijven, en elke kernelbug. Typische mislukking: de code leest een bestand waarvan je vergeten was dat het leesbaar was, of een „beperkte” taalinterpreter blijkt een achterdeur te hebben. De geschiedenis staat vol met sandboxes binnen een taal die het niet hielden.

De starttijd is praktisch nul. Prima voor je eigen code; geen grens voor die van een ander.

Niveau 2: een container

Namespaces geven de code een eigen blik op bestanden, processen en netwerk; cgroups begrenzen CPU en geheugen; ingetrokken capabilities en seccomp beperken wat hij aan de kernel mag vragen.

Houdt tegen: het lezen van hostbestanden (tenzij gemount), het zien van andere processen, onbeperkt resourcegebruik, een groot deel van het nestelprobleem als de container wordt weggegooid. Houdt niet tegen: een bug in de gedeelde hostkernel. Elke container op de machine praat met dezelfde kernel, dus een bereikbare kernelkwetsbaarheid is een uitgang. Typische mislukking: configuratie in plaats van exotische exploits. Een geprivilegieerde container, de socket van de container-runtime naar binnen gemount, hostnetwerk aangezet „alleen om te debuggen”. Elk daarvan haalt de grens stilletjes weg.

De starttijd is milliseconden. Er bestaan geharde varianten, waaronder kernels in user space die systeemaanroepen onderscheppen voordat ze de host bereiken, ten koste van snelheid en compatibiliteit. Voor code van mensen die je vertrouwt, is een goed geconfigureerde container een verstandige standaard.

Niveau 3: een microVM

Een microVM draait een eigen kernel onder een hypervisor, net als een volledige VM, maar met vrijwel geen geëmuleerde hardware. Het bekendste voorbeeld is Firecracker.

Houdt tegen: alles wat een container tegenhoudt, plus het probleem van de gedeelde kernel. Om de host te bereiken moet code de hypervisor breken of een van een handvol virtuele apparaten, een veel kleiner oppervlak dan de systeemaanroep-interface van een kernel. Houdt niet tegen: misbruik van wat je hem meegeeft. Open uitgaand verkeer kan nog steeds worden misbruikt; geïnjecteerde geheimen kunnen nog steeds lekken. Typische mislukking: beleid, niet isolatie. Iemand geeft een productietoken door „zodat de tests werken”, of laat uitgaand verkeer onbeperkt waar het niet nodig is.

De starttijd ligt tussen een fractie van een seconde en ongeveer een seconde, met een paar megabyte overhead. Dat is snel genoeg om er per taak één aan te maken en daarna te verwijderen, wat meteen het nestelen oplost: er is niets meer om naar terug te keren.

Niveau 4: een volledige virtuele machine

Een gewone VM, of een VPS, heeft hetzelfde soort grens als een microVM: hardwarevirtualisatie en een hypervisor. Het verschil zit in alles eromheen: een volledig apparaatmodel, een heel besturingssysteem, desgewenst een publiek IP, en een levenscyclus in dagen of maanden.

Houdt tegen: dezelfde soorten problemen als een microVM, met een iets groter aanvalsoppervlak omdat er meer hardware wordt geëmuleerd. Houdt niet tegen: misbruik van zijn eigen netwerkidentiteit. Een VM met een publiek IP die misbruikende code draait, brengt zijn IP op blocklists, wat ertoe doet als hetzelfde IP je e-mail verstuurt. (Is dat al gebeurd, zie wat te doen als je IP op een blocklist staat.) Typische mislukking: hij leeft te lang. Een VM die voor één experiment is gemaakt, verzamelt inloggegevens en status en wordt langzaam de vertrouwde machine die hij moest beschermen.

De starttijd is tientallen seconden tot minuten, en de facturering is meestal per maand. Dat is de juiste vorm voor een langlopende dienst die inkomende poorten nodig heeft, en de verkeerde voor een coderun van 20 seconden.

De vergelijking

Kiezen

• Code die jij of je team schreef: een proces of container volstaat.
• CI voor je eigen branches: een container op je runner.
• Code van agents, inzendingen van gebruikers, externe pull requests: een microVM per taak, daarna verwijderd.
• Een onbetrouwbare dienst die verbindingen moet accepteren of weken moet draaien: een aparte VM met een eigen IP, ver weg van alles wat je inloggegevens bewaart of je e-mail verstuurt.

Wat je ook kiest, er gelden twee regels bovenop: stop er niets in wat je niet aan de auteur van de code zou geven, en bepaal bewust wat het netwerk mag.

Waar onze producten staan

Voor niveau 3 hebben we code-sandboxes: Firecracker-microVM's die in ongeveer een seconde starten, met uitgaand internet, zonder inkomende poorten en met facturering per seconde. Ze zijn precies bedoeld voor het derde punt hierboven; de pagina MCP-beveiligingen beschrijft hoe je beperkt wat een agent ermee mag. Voor niveau 4 geeft een VPS zoals het tarief AI agent je een hele machine per maand. De uitgewerkte voorbeelden in sandbox voor AI-agents tonen het microVM-patroon van begin tot eind, en wat AI-agents echt van infrastructuur nodig hebben bekijkt isolatie als een van meerdere vereisten.