Container- eller microVM-isolering: 4 nivåer jämförda, från underprocess till fullständig VM

”Kör det i en sandbox” låter som en enda instruktion. I praktiken menar folk fyra vanliga gränser med det, och de stoppar väldigt olika saker. Fel val lämnar dig antingen oskyddad eller gör varje körning långsammare och dyrare än nödvändigt.

Den här jämförelsen utgår från att koden verkligen är opålitlig: skriven av en språkmodell, inskickad av en användare eller inkommen i en pull request från någon du inte känner. Kod du skrivit själv har andra behov.

Vad som kan gå fel

Innan vi jämför gränser hjälper det att namnge vad de är till för. Opålitlig kod kan:

1. Läsa sådant den inte ska: miljövariabler, SSH-nycklar, filer i din hemkatalog, molnets metadataslutpunkter.
2. Uttömma resurser: loopa för evigt, forka tills maskinen står still, fylla disken.
3. Missbruka nätverket: skanna andra värdar, skicka spam, mina kryptovaluta, anropa dina interna tjänster.
4. Bita sig fast: installera ett cron-jobb eller en tjänst som överlever uppgiften.
5. Ta sig ut: använda en bugg i lagret under för att köra kod på själva värden.

Varje nivå nedan hanterar en del av detta, inte allt.

Nivå 1: en process

Den enklaste sandboxen är en barnprocess: subprocess.run med en timeout, kanske under en egen användare, med resursgränser och ett seccomp-filter om man är noggrann.

Stoppar: oändlig körning (timeouten), en del resursuttömning (gränser), vissa farliga systemanrop (seccomp). Stoppar inte: läsning av allt den användaren kan läsa, nätverksåtkomst, fastbitning via allt användaren kan skriva till, och vilken kärnbugg som helst. Typiskt misslyckande: koden läser en fil du glömt var läsbar, eller en ”begränsad” språktolk visar sig ha en bakdörr. Historien är full av sandboxar inuti språk som inte höll.

Starttiden är i praktiken noll. Bra för din egen kod; ingen gräns för andras.

Nivå 2: en container

Namespaces ger koden en egen vy av filer, processer och nätverk; cgroups begränsar CPU och minne; borttagna capabilities och seccomp snävar in vad den kan be kärnan om.

Stoppar: läsning av värdens filer (om de inte är monterade), insyn i andra processer, obegränsad resursanvändning, större delen av fastbitningsproblemet om containern slängs. Stoppar inte: en bugg i värdens delade kärna. Alla containrar på maskinen pratar med samma kärna, så en nåbar kärnsårbarhet är en utgång. Typiskt misslyckande: konfiguration snarare än exotiska exploits. En privilegierad container, container-runtimens socket monterad inuti, värdens nätverk påslaget ”bara för felsökning”. Var och en tar bort gränsen i tysthet.

Starttiden är millisekunder. Det finns härdade varianter, bland annat kärnor i användarutrymmet som fångar systemanrop innan de når värden, till priset av hastighet och kompatibilitet. För kod från folk du litar på är en välkonfigurerad container ett rimligt standardval.

Nivå 3: en microVM

En microVM kör en egen kärna under en hypervisor, som en fullständig VM, men nästan utan emulerad hårdvara. Det mest kända exemplet är Firecracker.

Stoppar: allt en container stoppar, plus problemet med den delade kärnan. För att nå värden måste koden bryta hypervisorn eller en av en handfull virtuella enheter, en betydligt mindre yta än en kärnas gränssnitt för systemanrop. Stoppar inte: missbruk av det du ger den. Öppen utgående trafik kan fortfarande missbrukas; injicerade hemligheter kan fortfarande läcka. Typiskt misslyckande: policy, inte isolering. Någon skickar med en produktionstoken ”så att testerna fungerar”, eller lämnar utgående trafik obegränsad där den inte behövs.

Starttiden ligger mellan en bråkdel av en sekund och ungefär en sekund, med några megabyte overhead. Det är snabbt nog för att skapa en per uppgift och radera den efteråt, vilket samtidigt löser fastbitningen: det finns inget kvar att återvända till.

Nivå 4: en fullständig virtuell maskin

En vanlig VM, eller en VPS, har samma slags gräns som en microVM: hårdvaruvirtualisering och en hypervisor. Skillnaden ligger i allt runt omkring: en fullständig enhetsmodell, ett helt operativsystem, en publik IP om du vill, och en livscykel som mäts i dagar eller månader.

Stoppar: samma typer av problem som en microVM, med något större attackyta eftersom mer hårdvara emuleras. Stoppar inte: missbruk av sin egen nätverksidentitet. En VM med publik IP som kör skadlig kod hamnar med sin IP på blocklistor, vilket spelar roll om samma IP skickar din e-post. (Har det redan hänt, se vad du gör när din IP står på en blocklista.) Typiskt misslyckande: den lever för länge. En VM som skapats för ett experiment samlar på sig inloggningsuppgifter och tillstånd och blir sakta den betrodda maskin den skulle skydda.

Starttiden är tiotals sekunder till minuter, och debiteringen sker oftast per månad. Det är rätt form för en långlivad tjänst som behöver inkommande portar, och fel form för en kodkörning på 20 sekunder.

Jämförelsen

Att välja

• Kod som du eller ditt team skrivit: en process eller container räcker.
• CI för dina egna brancher: en container på din runner.
• Kod från agenter, inskick från användare, externa pull requests: en microVM per uppgift, raderad efteråt.
• En opålitlig tjänst som måste ta emot anslutningar eller köra i veckor: en separat VM med egen IP, långt från allt som har dina inloggningsuppgifter eller skickar din e-post.

Vad du än väljer gäller två regler ovanpå: lägg inget inuti som du inte skulle ge till kodens författare, och bestäm medvetet vad nätverket får göra.

Var våra produkter står

För nivå 3 har vi kodsandboxar: Firecracker-microVM:er som startar på ungefär en sekund, med utgående internet, utan inkommande portar och med debitering per sekund. De riktar sig precis mot den tredje punkten ovan; sidan MCP-skydd beskriver hur du begränsar vad en agent får göra med dem. För nivå 4 ger en VPS som tariffen AI agent dig en hel maskin per månad. De genomarbetade exemplen i sandbox för AI-agenter visar microVM-mönstret från början till slut, och vad AI-agenter verkligen behöver av infrastruktur ser på isolering som ett av flera krav.