Контейнер чи microVM: порівняння 4 рівнів ізоляції, від підпроцесу до повноцінної VM

«Запусти це в пісочниці» звучить як одна інструкція. На практиці під нею мають на увазі чотири поширені межі, і зупиняють вони дуже різне. Помилка у виборі або лишає вас вразливими, або робить кожен запуск повільнішим і дорожчим, ніж треба.

Порівняння виходить із того, що код справді недовірений: написаний мовною моделлю, надісланий користувачем або прийшов у pull request від незнайомця. У коду, який ви написали самі, інші потреби.

Що може піти не так

Перш ніж порівнювати межі, корисно назвати, від чого вони. Недовірений код може:

1. Прочитати зайве: змінні оточення, SSH-ключі, файли в домашньому каталозі, ендпоінти метаданих хмари.
2. Вичерпати ресурси: зациклитися, наплодити процесів до зупинки машини, забити диск.
3. Зловживати мережею: сканувати інші хости, слати спам, майнити, звертатися до ваших внутрішніх сервісів.
4. Закріпитися: поставити cron-задачу чи сервіс, що переживе задачу.
5. Вирватися: використати баг нижнього шару, щоб виконати код на самому хості.

Кожен рівень нижче впорається з частиною цього, але не з усім.

Рівень 1: процес

Найпростіша пісочниця — дочірній процес: subprocess.run з таймаутом, можливо від окремого користувача, з лімітами ресурсів і фільтром seccomp, якщо ви прискіпливі.

Зупиняє: нескінченне виконання (таймаут), частину вичерпання ресурсів (ліміти), частину небезпечних системних викликів (seccomp). Не зупиняє: читання всього, що може прочитати цей користувач, доступ до мережі, закріплення через усе, куди користувач може писати, і будь-який баг ядра. Типовий провал: код читає файл, про який забули, що він доступний, або «обмежений» інтерпретатор мови виявляється з лазівкою. Історія повна пісочниць усередині мови, які не встояли.

Час старту фактично нульовий. Годиться для свого коду; не межа для чужого.

Рівень 2: контейнер

Namespaces дають коду власний вигляд файлів, процесів і мережі; cgroups обмежують CPU і пам'ять; урізані capabilities та seccomp звужують те, що він може попросити в ядра.

Зупиняє: читання файлів хоста (якщо їх не змонтовано), перегляд інших процесів, необмежене споживання ресурсів, більшу частину проблеми закріплення, якщо контейнер викидається. Не зупиняє: баг у спільному ядрі хоста. Усі контейнери на машині говорять з одним ядром, тож досяжна вразливість ядра — це вихід. Типовий провал: конфігурація, а не екзотичні експлойти. Привілейований контейнер, сокет рантайму контейнерів, змонтований усередину, мережа хоста, увімкнена «лише для налагодження». Кожне з цього тихо прибирає межу.

Час старту — мілісекунди. Є посилені варіанти, зокрема ядра в просторі користувача, що перехоплюють системні виклики до того, як вони дійдуть до хоста, ціною швидкості й сумісності. Для коду від людей, яким ви довіряєте, добре налаштований контейнер — розумний вибір за замовчуванням.

Рівень 3: microVM

MicroVM запускає власне ядро під гіпервізором, як повноцінна VM, але майже без емульованого заліза. Найвідоміший приклад — Firecracker.

Зупиняє: усе, що зупиняє контейнер, плюс проблему спільного ядра. Щоб дістатися хоста, коду треба зламати гіпервізор або один із жмені віртуальних пристроїв — поверхня куди менша, ніж інтерфейс системних викликів ядра. Не зупиняє: зловживання тим, що ви самі йому віддали. Відкритий вихідний трафік усе ще можна використати на зло; впроваджені секрети все ще можуть витекти. Типовий провал: політика, а не ізоляція. Хтось передає бойовий токен, «щоб тести запрацювали», або лишає вихідний трафік без обмежень там, де він не потрібен.

Час старту — від часток секунди до приблизно секунди, з кількома мегабайтами накладних витрат. Це досить швидко, щоб створювати по одній на задачу й видаляти після, що заразом розв'язує проблему закріплення: повертатися просто нікуди.

Рівень 4: повноцінна віртуальна машина

Звичайна VM чи VPS має межу того самого типу, що й microVM: апаратна віртуалізація й гіпервізор. Різниця в усьому навколо: повна модель пристроїв, ціла ОС, публічний IP за бажання та життєвий цикл у днях чи місяцях.

Зупиняє: ті самі класи проблем, що й microVM, з дещо більшою поверхнею атаки, бо емулюється більше заліза. Не зупиняє: зловживання її власною мережевою ідентичністю. VM з публічним IP, на якій працює шкідливий код, отримує свій IP у блок-листи, а це важливо, якщо з того самого IP іде ваша пошта. (Якщо це вже сталося, див. що робити, якщо ваш IP у блок-листі.) Типовий провал: вона живе надто довго. VM, створена для одного експерименту, обростає обліковими даними й станом і поступово стає тією самою довіреною машиною, яку мала захищати.

Час старту — від десятків секунд до хвилин, оплата зазвичай помісячна. Це правильна форма для довгоживучого сервісу, якому потрібні вхідні порти, і неправильна — для запуску коду на 20 секунд.

Порівняння

Як обрати

• Код, написаний вами чи командою: процесу чи контейнера досить.
• CI для своїх гілок: контейнер на вашому раннері.
• Код від агентів, надісланий користувачами, зовнішні pull request: microVM на задачу, з видаленням після.
• Недовірений сервіс, що має приймати підключення чи працювати тижнями: окрема VM із власним IP, подалі від усього, що зберігає ваші облікові дані чи надсилає вашу пошту.

Хоч би що ви обрали, згори діють два правила: не кладіть усередину нічого, чого не віддали б авторові коду, і свідомо вирішуйте, що може робити мережа.

Де наші продукти

Для рівня 3 у нас є пісочниці для коду: Firecracker microVM, що стартують приблизно за секунду, з вихідним інтернетом, без вхідних портів і з посекундною оплатою. Вони націлені саме на третій пункт вище; як обмежити, що агент може з ними робити, описано в розділі захист MCP. Для рівня 4 VPS на кшталт тарифу AI agent дає цілу машину помісячно. Розібрані приклади в пісочниці для ШІ-агентів показують патерн із microVM від початку до кінця, а що ШІ-агентам насправді потрібно від інфраструктури розглядає ізоляцію як одну з кількох вимог.