Якщо ви читали щось про безпечний запуск згенерованого ШІ коду, ви бачили слово microVM, зазвичай поруч із Firecracker. Його пояснюють або як «легку VM» (правда, але марно), або схемою нутрощів ядра. Ось версія посередині.
Два старі варіанти й чому жоден не підходить
Почнемо з того, між чим стоїть microVM.
Контейнер — це група звичайних процесів на вашій машині, яким ядро погодилося брехати. Namespaces показують їм власні файлову систему, список процесів і мережу; cgroups обмежують, скільки CPU й пам'яті їм можна брати. Він стартує за мілісекунди, бо нічого нового не завантажується. Але всі контейнери на хості говорять з одним і тим самим ядром. Баг ядра, досяжний з одного контейнера, — це вихід з усіх.
Віртуальна машина приносить власне ядро. Процесор хоста через апаратну віртуалізацію (KVM у Linux) виконує гостя так, ніби той має власний комп'ютер. Межа — гіпервізор, який відкриває куди менше, ніж сотні системних викликів ядра. Розплата — вага. Класична VM емулює цілий ПК: прошивку, шину PCI, контролери USB, відеокарту, іноді звукову карту. Вона вантажиться крізь усе це, стартує від секунд до хвилин, і кожен екземпляр несе десятки чи сотні мегабайтів накладних витрат.
Аналогія, яка непогано тримається: контейнери — квартири в одному будинку, зі спільними фундаментом, трубами й проводкою. VM — окремі будинки. Будинки — безпечніші сусіди, але заради візиту на 20 секунд будинок не будують.
Що викидає Firecracker
Firecracker — це монітор віртуальних машин (програма, що налаштовує й запускає VM поверх KVM), написаний на Rust і відкритий у 2018 році. Він зроблений для однієї задачі: запускати величезну кількість короткоживучих навантажень, що не довіряють одне одному, на спільному залізі. Досягається це здебільшого видаленням:
- Немає прошивки й пошуку обладнання. Ядро завантажується просто в пам'ять і запускається. Ніхто не шукає пристроїв, яких немає.
- Крихітна модель пристроїв. Мережева карта, блочний пристрій, послідовна консоль і ще кілька, усі virtio (пристрої, задумані для віртуальних машин, а не імітація фізичних). Ні USB, ні графіки, ні PCI.
- Маленька кодова база з безпечною роботою з пам'яттю. Менше коду, що емулює пристрої, — менше місць для бага, через який гість дотягнеться до хоста.
- Клітка навколо самого VMM. Кожен процес Firecracker працює в chroot, із фільтрами seccomp на його власні системні виклики та cgroups на ресурси. Якщо щось і вирветься з гостя, воно опиниться в клітці, а не на хості.
Опубліковані самим проєктом цифри: user space за 125 мс і менше 5 MiB накладних витрат пам'яті на microVM. Це найкращі лабораторні значення; справжній пісочниці ще треба підготувати диск і мережу та дочекатися агента всередині, готового приймати команди, тому наша готова приблизно за секунду. Це все одно достатньо близько до швидкості контейнера, щоб створювати по одній на задачу й викидати після.
Контейнер і microVM на практиці
| Контейнер | Firecracker microVM | |
|---|---|---|
| Ядро | спільне з хостом | власне |
| Межа з хостом | системні виклики в спільне ядро | гіпервізор + маленький VMM |
| Час старту | мілісекунди | ~0.1–1 с |
| Накладні витрати на екземпляр | дуже малі | кілька MiB |
| Пристрої | що відкриє хост | мережа, диск, консоль |
| GPU | можливий | ні |
| Підходить для | свого коду, пакування застосунків | недовіреного коду, мультиорендних навантажень |
Важливий рядок — другий. З контейнером питання «чи може цей код вирватися?» перетворюється на «чи є десь у ядрі хоста досяжний баг?». З microVM — на «чи є баг у гіпервізорі або в жмені віртуальних пристроїв?». Друга поверхня набагато менша, і саме її хмарні платформи й так захищають для власного мультиорендного хостингу.
Чим платите
MicroVM — не безкоштовний апгрейд.
- Немає GPU й дисплеїв. Це для запуску коду, а не для робочих столів і графіки.
- Менше пристроїв — менше гнучкості. Усе, що чекає справжнього заліза чи довгого списку модулів ядра, почуватиметься незатишно.
- Межам усе одно потрібна політика. MicroVM з відкритим вихідним трафіком усе ще може слати трафік, який вам не потрібен; із вашими API-ключами всередині — усе ще може їх злити. Ізоляція захищає хост від гостя, а не ваші секрети від коду, якому ви їх віддали.
Як це використовують наші пісочниці
Кожна пісочниця EQVPS — це одна Firecracker microVM із власним ядром, від 0.25 vCPU і 512 MB до 8 vCPU і 16 GB. У ній Python 3.12, Node.js 22, bash, git і curl, вихідний інтернет є, вхідних портів немає. Тимчасові пісочниці видаляються, коли ви закінчили; persistent зберігають диск, а постановка на паузу записує снапшот microVM на диск, тож вона нічого не коштує до відновлення. Снапшоти на паузі зберігаються 14 днів. Потім пісочниця видаляється, і її id відповідає 410 sandbox_deleted.
Ми обрали microVM замість контейнерів з однієї причини: код у пісочниці за визначенням ніхто не перевіряв. Вивід ШІ-агента, pull request незнайомця, бенчмарк із тисячі програм, написаних моделлю. Для такого власне ядро — межа, за яку варто платити. Подробиці того, що ми збудували навколо, — тарифи, квоти, ліміт синхронної команди в 55 секунд — у документації пісочниць.
Якщо хочете глибше порівняти цю межу з іншими варіантами, у рівнях ізоляції для недовіреного коду процеси, контейнери, microVM і повноцінні VM стоять поруч. А якщо увагу привернула посекундна ціна, як насправді працює посекундна оплата показує арифметику.
Коментарі
Поки немає коментарів. Будьте першим.