Izolacja: kontener czy microVM — 4 poziomy w porównaniu, od podprocesu po pełną VM

„Uruchom to w sandboxie” brzmi jak jedno polecenie. W praktyce kryją się pod nim cztery popularne granice, a zatrzymują one bardzo różne rzeczy. Zły wybór albo zostawia cię bez ochrony, albo sprawia, że każde uruchomienie jest wolniejsze i droższe, niż trzeba.

To porównanie zakłada, że kod jest naprawdę niezaufany: napisany przez model językowy, przesłany przez użytkownika albo nadesłany w pull requeście od kogoś, kogo nie znasz. Kod, który napisałeś sam, ma inne potrzeby.

Co może pójść nie tak

Zanim porównamy granice, warto nazwać, przed czym chronią. Niezaufany kod może:

1. Przeczytać to, czego nie powinien: zmienne środowiskowe, klucze SSH, pliki w katalogu domowym, punkty końcowe metadanych chmury.
2. Wyczerpać zasoby: zapętlić się w nieskończoność, forkować do zatrzymania maszyny, zapełnić dysk.
3. Nadużyć sieci: skanować inne hosty, wysyłać spam, kopać kryptowaluty, wywoływać twoje usługi wewnętrzne.
4. Zagnieździć się: zainstalować zadanie cron lub usługę, która przetrwa zadanie.
5. Uciec: wykorzystać błąd warstwy niżej, by wykonać kod na samym hoście.

Każdy poziom poniżej radzi sobie z częścią tego, ale nie ze wszystkim.

Poziom 1: proces

Najprostszy sandbox to proces potomny: subprocess.run z limitem czasu, może pod osobnym użytkownikiem, z limitami zasobów i filtrem seccomp, jeśli jesteś skrupulatny.

Zatrzymuje: nieskończone wykonanie (limit czasu), część wyczerpania zasobów (limity), niektóre niebezpieczne wywołania systemowe (seccomp). Nie zatrzymuje: odczytu wszystkiego, co może przeczytać ten użytkownik, dostępu do sieci, zagnieżdżenia przez wszystko, do czego użytkownik może pisać, i żadnego błędu jądra. Typowa porażka: kod czyta plik, o którym zapomniałeś, że jest czytelny, albo „ograniczony” interpreter języka okazuje się mieć furtkę. Historia jest pełna sandboxów wewnątrz języka, które nie wytrzymały.

Czas startu jest praktycznie zerowy. Dobre dla własnego kodu; to nie granica dla cudzego.

Poziom 2: kontener

Namespaces dają kodowi własny widok plików, procesów i sieci; cgroups ograniczają CPU i pamięć; odebrane capabilities i seccomp zawężają to, o co może prosić jądro.

Zatrzymuje: odczyt plików hosta (o ile nie są zamontowane), podgląd innych procesów, nieograniczone zużycie zasobów, większą część problemu zagnieżdżenia, jeśli kontener jest wyrzucany. Nie zatrzymuje: błędu we wspólnym jądrze hosta. Wszystkie kontenery na maszynie rozmawiają z tym samym jądrem, więc osiągalna podatność jądra to wyjście. Typowa porażka: konfiguracja, a nie egzotyczne exploity. Uprzywilejowany kontener, gniazdo środowiska kontenerów zamontowane do środka, sieć hosta włączona „tylko do debugowania”. Każde z nich po cichu usuwa granicę.

Czas startu to milisekundy. Istnieją wzmocnione warianty, w tym jądra w przestrzeni użytkownika, które przechwytują wywołania systemowe, zanim dotrą do hosta, kosztem szybkości i zgodności. Dla kodu od ludzi, którym ufasz, dobrze skonfigurowany kontener to rozsądny domyślny wybór.

Poziom 3: microVM

MicroVM uruchamia własne jądro pod hipernadzorcą, jak pełna VM, ale prawie bez emulowanego sprzętu. Najbardziej znanym przykładem jest Firecracker.

Zatrzymuje: wszystko, co zatrzymuje kontener, plus problem wspólnego jądra. Żeby dostać się do hosta, kod musi złamać hipernadzorcę albo jedno z garstki wirtualnych urządzeń — powierzchnię znacznie mniejszą niż interfejs wywołań systemowych jądra. Nie zatrzymuje: nadużycia tego, co mu dasz. Otwarty ruch wychodzący wciąż można wykorzystać; wstrzyknięte sekrety wciąż mogą wyciec. Typowa porażka: zasady, a nie izolacja. Ktoś przekazuje produkcyjny token, „żeby testy działały”, albo zostawia ruch wychodzący bez ograniczeń tam, gdzie nie jest potrzebny.

Czas startu wynosi od ułamka sekundy do około sekundy, przy kilku megabajtach narzutu. To wystarczająco szybko, by tworzyć jedną na zadanie i usuwać ją potem, co przy okazji rozwiązuje problem zagnieżdżenia: nie ma już do czego wracać.

Poziom 4: pełna maszyna wirtualna

Zwykła VM albo VPS ma granicę tego samego rodzaju co microVM: wirtualizację sprzętową i hipernadzorcę. Różnica tkwi w całej reszcie: pełny model urządzeń, cały system operacyjny, publiczny IP, jeśli chcesz, i cykl życia liczony w dniach lub miesiącach.

Zatrzymuje: te same klasy problemów co microVM, z nieco większą powierzchnią ataku, bo emulowane jest więcej sprzętu. Nie zatrzymuje: nadużycia własnej tożsamości sieciowej. VM z publicznym IP, na której działa szkodliwy kod, trafia z własnym IP na listy blokad, co ma znaczenie, jeśli ten sam IP wysyła twoją pocztę. (Jeśli to już się stało, zobacz co zrobić, gdy twój IP jest na liście blokad.) Typowa porażka: żyje za długo. VM utworzona do jednego eksperymentu obrasta danymi logowania i stanem i powoli staje się zaufaną maszyną, którą miała chronić.

Czas startu to od dziesiątek sekund do minut, a rozliczenie jest zwykle miesięczne. To właściwa forma dla długo działającej usługi, która potrzebuje portów przychodzących, i niewłaściwa dla uruchomienia kodu na 20 sekund.

Porównanie

Jak wybrać

• Kod napisany przez ciebie lub zespół: wystarczy proces lub kontener.
• CI dla własnych gałęzi: kontener na twoim runnerze.
• Kod od agentów, zgłoszenia użytkowników, zewnętrzne pull requesty: microVM na zadanie, usuwana potem.
• Niezaufana usługa, która musi przyjmować połączenia lub działać tygodniami: osobna VM z własnym IP, z dala od wszystkiego, co przechowuje twoje dane logowania lub wysyła twoją pocztę.

Cokolwiek wybierzesz, na wierzch obowiązują dwie zasady: nie wkładaj do środka niczego, czego nie dałbyś autorowi kodu, i świadomie decyduj, co wolno sieci.

Gdzie są nasze produkty

Dla poziomu 3 oferujemy sandboxy do kodu: microVM Firecracker, które startują w około sekundę, z internetem wychodzącym, bez portów przychodzących i z rozliczaniem za sekundę. Są skierowane dokładnie na trzeci punkt powyżej; jak ograniczyć, co agent może z nimi robić, opisuje strona zabezpieczenia MCP. Dla poziomu 4 VPS taki jak taryfa AI agent daje ci całą maszynę na miesiąc. Rozpisane przykłady w sandboxie dla agentów AI pokazują wzorzec z microVM od początku do końca, a czego agenci AI naprawdę potrzebują od infrastruktury traktuje izolację jako jeden z kilku wymogów.