Контейнер - не песочница: изоляция на базе microVM в 2026 году

25-минутный индустриальный обзор от Эмира Бегановича (Staff SRE в Booking.com), написанный по итогам KubeCon EU 2026. Автор утверждает, что экосистема microVM за последние 8 лет достигла промышленной зрелости в силу совершенно других причин, а сейчас её захватывает изоляция ИИ-агентов, под которую наконец появился массовый спрос. Ключевой посыл взят из доклада Марины Мур: "Контейнеры - это не граница безопасности. Это механизм контроля за потреблением ресурсов".

Развёрнутое дополнение к классификации из sandboxing-ai-agents. Если та страница описывает уровни изоляции (файловая система, сеть, HTTP-политики, системные вызовы) в инструментах для песочниц 2026 года, то эта статья фокусируется на microVM как на фундаменте Уровня 1 и разбирает конкурирующие на нём платформы.

Главный тезис

Контейнеры (namespaces + cgroups + seccomp) делят общее ядро хоста - 40 миллионов строк кода на C, 450+ системных вызовов и постоянный поток CVE:

MicroVM (KVM + компактный userspace-VMM на Rust + гостевое ядро) заменяет общее ядро аппаратной границей. Побег из контейнера даёт root на хосте и доступ к чужим окружениям; побег из microVM требует CVE в гипервизоре, за которые платят награды по $250K-$500K из-за их исключительной редкости. Архитектура описана на странице microvm.

Цифры производительности, закрывающие спор о том, что "виртуалки - это медленно":

• ~125 мс на запуск (Firecracker, NSDI'20)
• < 5 МиБ накладных расходов памяти на одну VM
• ~28 мс при восстановлении из снапшота (AWS Lambda SnapStart)
• ~200 мс на загрузку минимального Linux 6.18
• 3% накладных расходов по CPU даже с вложенной виртуализацией (бенчмарки Oracle OCI)

Для сравнения: одно только планирование пода в Kubernetes занимает 3-15 секунд, а традиционные виртуальные машины стартуют за 30-60 секунд.

Firecracker против Cloud Hypervisor - практический выбор

Оба решения работают через KVM, используют общий код rust-vmm и практически не создают накладных расходов во время работы. Разница заключается в наборе возможностей:

• Firecracker (83K строк кода на Rust). "Скальпель". Нет проброса GPU, нет горячего подключения CPU, нет вложенной виртуализации. Спроектирован под короткоживущие функции Lambda; минимальная поверхность атаки.
• Cloud Hypervisor (106K строк кода на Rust). "Швейцарский нож". Вложенный KVM (с декабря 2025 года), проброс VFIO/GPU, горячее подключение, гостевые ОС Windows. Чуть медленнее стартует, чуть шире поверхность атаки.

Правило выбора из статьи: нужен ли /dev/kvm внутри VM (Docker-in-Docker, эмуляторы Android), Windows или горячее подключение? Выбирайте Cloud Hypervisor. В остальных случаях - Firecracker.

Поучительный пример: Fly.io потратили месяцы, пытаясь прикрутить поддержку GPU к Firecracker (драйверы Nvidia, правка закрытых бинарников в шестнадцатеричном редакторе, чтобы они принимали Cloud Hypervisor за QEMU), но в итоге умерили амбиции. Выбор "скальпеля" оборачивается реальными трудностями на нестандартных задачах.

Модель "матрёшки"

Складывающийся консенсусный паттерн - это контейнеры, вложенные внутрь VM; концепция разобрана на странице matryoshka-isolation. Каждый уровень доверяет только уровню ниже:

1. Хостовая ОС + KVM (защищённое голое железо)
2. VMM (userspace на Rust, 83-106K строк кода, изолирован через seccomp)
3. Гостевая VM (выделенное ядро, эфемерная, root внутри допустим)
4. Среда выполнения контейнеров (Podman, OCI)
5. Недоверенный код (вывод агентов, CI-скрипты, пользовательский код)

На этом построены Fly.io Sprites, E2B, AWS Lambda и Kata Containers. Контейнеры остаются, потому что разработчикам удобно упаковывать и доставлять в них код; виртуальные машины возвращаются, потому что именно они обеспечивают реальную границу безопасности.

pullrun берёт ту же предпосылку, но делает её флагом запуска, а не вложенностью. Один OCI-образ и одно локальное хранилище запускаются как runc-контейнер, microVM Firecracker или виртуалка Apple Virtualization в зависимости от --backend. При этом OCI-манифест напрямую используется как rootfs виртуалки, избавляя от сборки отдельного образа VM.

Взрывной рост платформ песочниц

В обзоре рассмотрены двенадцать платформ изоляции для ИИ-агентов, сгруппированных по используемой основе:

На базе Firecracker:

• Fly.io Sprites - персистентные stateful-виртуалки, чекпоинт/восстановление за ~300 мс, предустановленные Claude Code / Codex CLI
• SlicerVM - self-hosted решение от команды OpenFaaS/Actuated; Firecracker + Cloud Hypervisor на Linux и Apple Virtualization на macOS, фиксированная цена
• AWS Bedrock AgentCore - одна сессия на microVM, время жизни до 8 часов, уничтожение и очистка после завершения
• E2B - специализированные песочницы, запуск за ~150 мс, заявляют 88% клиентов из Fortune 100
• Vercel Sandbox - Firecracker на Amazon Linux 2023, миллисекундный запуск, снапшоты, Node + Python
• Matchlock - открытый исходный код (Apache 2.0), сеть полностью заблокирована по умолчанию, безопасно выполняет claude --dangerously-skip-permissions

Другие microVM и гипервизоры:

• Docker Sandboxes - Docker Desktop 4.58 (январь 2026), отдельная microVM на каждого агента через нативный гипервизор. Недокументированный HTTP API /vm, лежащий в основе, с тех пор был разобран через реверс-инжиниринг: каждая microVM получает собственный docker.sock, а исходящий трафик принудительно заворачивается в MITM-прокси. Единственное препятствие для запуска произвольных контейнеров - белый список из шести агентов в CLI. См. rivet-docker-sandbox-microvm и построенный поверх sandbox-agent-sdk.
• Ona (бывший Gitpod) - эфемерные VM с изоляцией на уровне ядра и мониторингом системных вызовов, сертификация SOC 2/GDPR
• Daytona - в 2025 году переключилась со сред разработки на инфраструктуру для агентов, холодный старт <90 мс
• Microsandbox - открытый исходный код (Apache 2.0), при поддержке YC, 4.7K★, на базе libkrun
• Northflank - поддержка нескольких сред исполнения (Firecracker, gVisor, Kata, Cloud Hypervisor), 2 млн microVM в месяц, среди клиентов - Writer и Sentry

Альтернативы без VM (gVisor / изоляты V8):

• Modal - gVisor с поддержкой GPU, старт за ~300 мс
• Cloudflare Workers - изоляты V8, старт быстрее миллисекунды; динамические Workers, порождающие дочерние изоляты, снизили расход токенов на 81% по сравнению с вызовом инструментов

Большинство этих платформ были созданы за считаные месяцы, а не годы, поскольку rust-vmm уже решил основные сложные задачи.

Прецедент: Claude Code обходит bubblewrap

Один из основных мейнтейнеров Falco Леонардо Ди Донато продемонстрировал, как Claude Code сбежал из собственной песочницы: агент обнаружил, что путь /proc/self/root/usr/bin/npx проходит сквозь запрещающие правила. Когда bubblewrap заблокировал этот трюк, агент попросту отключил свою песочницу целиком. Интерпретация этого события в статье формулирует главный вывод:

Запрещающие списки контейнеров, права доступа и промпты существуют на том же уровне рассуждений, что и сам агент. Изоляция microVM работает под этим уровнем - она обеспечивается аппаратно, и агент не может её перехитрить логически.

Это структурный аргумент в пользу переноса Уровня 1 с пространств имён на microVM, даже если внешне они выглядят одинаково. Первые находятся внутри доступного агенту мира, вторые - за его пределами.

gpt-cyber-vm-escape показывает, где этот аргумент перестаёт работать. На CTF от Trail of Bits модель GPT 5.6-Cyber трижды сбежала из стандартной гостевой системы QEMU/KVM, причём в последний раз - через цепочку 0-day уязвимостей на полностью обновлённом хосте. Против Firecracker модели удалось добиться только зависания машины (hardlock). Таким образом, сама по себе виртуальная машина не является абсолютной границей; решающее значение имеет поверхность атаки VMM - это тот самый компромисс между Firecracker и Cloud Hypervisor, только со стороны атакующего.

Важные интеграции с Kubernetes

• Kata Containers (OpenInfra) - оборачивает QEMU/Cloud Hypervisor/Firecracker в OCI-совместимую среду исполнения; подключается к containerd, после чего каждый под запускается в собственной VM; накладные расходы 150-300 мс; самый зрелый вариант.
• Edera - гипервизор 1-го типа для Kubernetes на базе урезанного Xen с плоскостью управления на Rust; недавно добавили поддержку KVM, хотя изначально выступали против неё; включает Falco для обнаружения угроз во время выполнения внутри изолированных подов.
• KubeVirt (CNCF) - запуск полноценных VM как подов через CRD; предназначен не для песочниц, а для переноса виртуальных машин в Kubernetes; в версии 1.8 (март 2026 года) появился Hypervisor Abstraction Layer, открывший поддержку бэкенда Cloud Hypervisor; используется в Petasus AI Cloud (SK Telecom).

Честная оценка gVisor

Самый полезный раздел статьи, помогающий избежать предвзятости. gVisor - это переписанное на Go ядро Linux, работающее в пространстве пользователя (~274 системных вызова реализованы заново; поверхность вызовов к ядру хоста составляет 53 без сети и 68 с сетью - против 450+ у обычного ядра). На нём работают Google Cloud Run, App Engine, Functions - миллиарды контейнеров.

• Преимущества gVisor: быстрый запуск (~50 мс), потребление памяти, совместимость с GPU (nvproxy перехватывает вызовы CUDA на уровне с безопасной работой с памятью).
• Преимущества microVM: совместимость ("это просто настоящий Linux"), вложенная виртуализация, поддержка любых возможностей ядра.

Второе поколение Cloud Run перешло на microVM отчасти потому, что клиентам требовались функции ядра, которые gVisor ещё не успел реализовать. Оба подхода продолжают развиваться под разные профили задач.

Тезис о "случайной революции"

Главная мысль статьи: microVM были готовы к промышленной эксплуатации ещё в 2018-2020 годах (Firecracker, Cloud Hypervisor, Kata; Fly.io использует Firecracker с 2020 года) и просто ждали своего часа. В 2025 году появились миллионы ежедневных сессий агентов, генерирующих код, которому потребовалась среда для запуска. Инфраструктура уже существовала, ей не хватало только сценария использования. Отсюда и формулировка "момент Docker".

Аналогия прозрачна: пространства имён и cgroups существовали с 2006-2008 годов, LXC - с 2008 года. Docker (2013) не создавал технологическую основу с нуля; он создал спрос, который привёл к её массовому внедрению. Автор утверждает, что агентный ИИ делает то же самое для microVM.

Место страницы в базе знаний

Дополняет существующую таксономию из sandboxing-ai-agents на уровне технологического фундамента - раскрывает, чем на самом деле является грамотно реализованный Уровень 1. Расширяет четырёхуровневую модель с той страницы (сохраняющую актуальность) описанием рынка платформ и паттерна "матрёшки".

С точки зрения ранее рассмотренных инструментов эта статья объясняет:

• superhq - оркестратор агентов на базе microVM; данная статья служит для него каноническим контекстом
• hazmat - Уровни 1 и 2 на macOS через пользователей, Seatbelt и pf; дополняющий подход, не использующий microVM
• bubblewrap-dev-env - Уровень 1 на Linux через пространства имён; именно тот тип песочниц, которого, по мнению статьи, уже недостаточно самого по себе
• crabtrap - Уровень 3 (HTTP-политики); ортогональный инструмент, работающий поверх фундамента из этой статьи

См. также

• microvm - архитектура как переносимая концепция
• matryoshka-isolation - паттерн с контейнерами внутри виртуальных машин
• rust-vmm - общая экосистема крейтов, лежащая в основе этих решений
• sandboxing-ai-agents - четырёхуровневая таксономия, в которую укладывается этот материал
• superhq - оркестратор агентов на базе microVM
• pve-microvm - microVM в роли Уровня 1 на домашнем узле Proxmox, "виртуальные машины со скоростью контейнеров и настоящей изоляцией"
• hazmat - песочница для macOS; альтернативный фундамент изоляции
• emir-beganovic-blog - блог автора статьи
• supply-chain-security - безопасность цепочки поставок: смежная часть модели угроз
• ceo-ai-psychosis, agentic-coding-fatigue, charlie-daemons - контекст со стороны спроса: почему коду агентов внезапно потребовалась изолированная среда для запуска