Container- eller microVM-isolation: 4 niveauer sammenlignet, fra underproces til fuld VM

„Kør det i en sandbox“ lyder som én instruktion. I praksis mener folk fire almindelige grænser med det, og de stopper meget forskellige ting. Vælger du den forkerte, står du enten ubeskyttet, eller hver kørsel bliver langsommere og dyrere end nødvendigt.

Denne sammenligning forudsætter, at koden virkelig er upålidelig: skrevet af en sprogmodel, indsendt af en bruger eller ankommet i en pull request fra en, du ikke kender. Kode, du selv har skrevet, har andre behov.

Hvad der kan gå galt

Før vi sammenligner grænser, hjælper det at sætte navn på, hvad de skal beskytte mod. Upålidelig kode kan:

1. Læse det, den ikke må: miljøvariabler, SSH-nøgler, filer i din hjemmemappe, skyens metadata-endpoints.
2. Opbruge ressourcer: køre i ring for evigt, forke, til maskinen går i stå, fylde disken.
3. Misbruge netværket: scanne andre værter, sende spam, mine kryptovaluta, kalde dine interne tjenester.
4. Bide sig fast: installere et cron-job eller en tjeneste, der overlever opgaven.
5. Slippe ud: bruge en fejl i laget nedenunder til at køre kode på selve værten.

Hvert niveau herunder håndterer noget af dette, men ikke det hele.

Niveau 1: en proces

Den enkleste sandbox er en underproces: subprocess.run med en timeout, måske under en separat bruger, med ressourcegrænser og et seccomp-filter, hvis man er grundig.

Stopper: uendelig kørsel (timeouten), en del ressourceudtømning (grænser), visse farlige systemkald (seccomp). Stopper ikke: læsning af alt, hvad den bruger kan læse, netværksadgang, fastbidning via alt, brugeren kan skrive til, og enhver kernefejl. Typisk svigt: koden læser en fil, du havde glemt var læsbar, eller en „begrænset“ sprogfortolker viser sig at have en bagdør. Historien er fuld af sandboxe inde i et sprog, der ikke holdt.

Starttiden er reelt nul. Fint til din egen kode; ingen grænse for andres.

Niveau 2: en container

Namespaces giver koden sit eget syn på filer, processer og netværk; cgroups begrænser CPU og hukommelse; fjernede capabilities og seccomp indsnævrer, hvad den kan bede kernen om.

Stopper: læsning af værtens filer (medmindre de er monteret), indsyn i andre processer, ubegrænset ressourceforbrug, det meste af fastbidningsproblemet, hvis containeren smides væk. Stopper ikke: en fejl i værtens delte kerne. Alle containere på maskinen taler med den samme kerne, så en sårbarhed i kernen, der kan nås, er en udgang. Typisk svigt: konfiguration snarere end eksotiske exploits. En privilegeret container, container-runtimens socket monteret indeni, værtens netværk slået til „kun til fejlfinding“. Hver af dem fjerner grænsen i stilhed.

Starttiden er millisekunder. Der findes hærdede varianter, herunder kerner i brugerrummet, der opfanger systemkald, før de når værten, på bekostning af hastighed og kompatibilitet. Til kode fra folk, du stoler på, er en velkonfigureret container et fornuftigt standardvalg.

Niveau 3: en microVM

En microVM kører sin egen kerne under en hypervisor, ligesom en fuld VM, men næsten uden emuleret hardware. Det bedst kendte eksempel er Firecracker.

Stopper: alt, hvad en container stopper, plus problemet med den delte kerne. For at nå værten skal koden bryde hypervisoren eller en af en håndfuld virtuelle enheder, en langt mindre flade end en kernes grænseflade for systemkald. Stopper ikke: misbrug af det, du giver den. Åben udgående trafik kan stadig misbruges; injicerede hemmeligheder kan stadig lække. Typisk svigt: politik, ikke isolation. Nogen giver en produktionstoken videre, „så testene virker“, eller lader udgående trafik være ubegrænset, hvor den ikke er nødvendig.

Starttiden ligger mellem en brøkdel af et sekund og cirka et sekund, med et par megabyte overhead. Det er hurtigt nok til at oprette én pr. opgave og slette den bagefter, hvilket samtidig løser fastbidningen: der er intet tilbage at vende tilbage til.

Niveau 4: en fuld virtuel maskine

En almindelig VM, eller en VPS, har samme slags grænse som en microVM: hardwarevirtualisering og en hypervisor. Forskellen ligger i alt omkring den: en fuld enhedsmodel, et helt operativsystem, en offentlig IP, hvis du vil, og en livscyklus, der måles i dage eller måneder.

Stopper: de samme typer problemer som en microVM, med en noget større angrebsflade, fordi mere hardware emuleres. Stopper ikke: misbrug af dens egen netværksidentitet. En VM med offentlig IP, der kører skadelig kode, får sin IP på blokeringslister, hvilket betyder noget, hvis samme IP sender din e-mail. (Er det allerede sket, så se hvad du gør, når din IP står på en blokeringsliste.) Typisk svigt: den lever for længe. En VM, der er oprettet til ét eksperiment, samler loginoplysninger og tilstand og bliver langsomt den betroede maskine, den skulle beskytte.

Starttiden er flere titals sekunder til minutter, og afregningen er som regel pr. måned. Det er den rigtige form til en langvarig tjeneste, der har brug for indgående porte, og den forkerte til en kodekørsel på 20 sekunder.

Sammenligningen

Sådan vælger du

• Kode, du eller dit team har skrevet: en proces eller container er nok.
• CI for dine egne branches: en container på din runner.
• Kode fra agenter, indsendelser fra brugere, eksterne pull requests: en microVM pr. opgave, slettet bagefter.
• En upålidelig tjeneste, der skal modtage forbindelser eller køre i uger: en separat VM med egen IP, langt fra alt, der holder dine loginoplysninger eller sender din e-mail.

Uanset hvad du vælger, gælder to regler oveni: læg intet indeni, som du ikke ville give kodens forfatter, og beslut bevidst, hvad netværket må.

Hvor vores produkter står

Til niveau 3 har vi kodesandboxe: Firecracker-microVM'er, der starter på cirka et sekund, med udgående internet, uden indgående porte og med afregning pr. sekund. De er rettet præcis mod tredje punkt ovenfor; siden MCP-sikkerhedsforanstaltninger beskriver, hvordan du begrænser, hvad en agent må gøre med dem. Til niveau 4 giver en VPS som tariffen AI agent dig en hel maskine pr. måned. De gennemregnede eksempler i sandbox til AI-agenter viser microVM-mønsteret fra start til slut, og hvad AI-agenter virkelig har brug for fra infrastruktur ser på isolation som et af flere krav.