Изоляция-матрёшка (контейнеры внутри VM)

Модель "матрёшка" - это архитектура эшелонированной защиты для запуска ненадёжного кода, в которой контейнеры вложены внутрь microVM. Названа в честь русской куклы и вынесена как ключевой тезис в индустриальном обзоре Бегановича microvm-2026. Каждый слой задаёт чёткую границу доверия; злоумышленнику придётся пробить их все последовательно, чтобы скомпрометировать хост.

Слои модели:

Хостовая ОС + KVM - bare metal, минимальный набор пакетов, усиленная защита (hardened)
VMM - 83-106 тысяч строк на Rust, работающие непривилегированно в userspace, в seccomp-изоляции
Гостевая VM - собственное ядро, эфемерность, root допустим внутри VM, потому что для побега требуются CVE в гипервизоре
Контейнерный runtime - Podman, OCI-образы для упаковки и DX
Ненадёжный код - вывод AI-агентов, CI-скрипты, пользовательский ввод, сторонние плагины

Каждый слой доверяет только тому, что находится строго под ним. Слой контейнеров доверяет гостевому ядру; гостевое ядро доверяет VMM; VMM доверяет хосту. Атакующему, чей код выполняется на 5-м уровне, придётся обойти контейнерный runtime (4-й уровень), сбежать из гостевого ядра (3-й уровень), поэксплуатировать уязвимость в VMM (2-й уровень) и затем вырваться из KVM (1-й уровень), прежде чем он окажется на хосте. Каждый уровень достаточно компактен для аудита и достаточно зрелый, чтобы быть надёжно защищённым.

Почему это работает на практике

В неформальных спорах обычно смешивают два аспекта:

Контейнер = упаковка. Dockerfile, OCI-образ, послойная файловая система, декларативное окружение. Это ровно то, чего хотят разработчики, и то, что упрощает доставку готового приложения.
Контейнер = изоляция. Namespaces + cgroups + seccomp. А вот для этого контейнеры изначально не предназначались - как сформулировала Марина Мур (Marina Moore) в докладе на KubeCon 2026: "контейнеры - это не граница безопасности; это механизм управления потреблением ресурсов".

Паттерн матрёшки оставляет первую часть ("контейнер = упаковка") для всего пользовательского интерфейса, а вторую часть ("контейнер = изоляция") заменяет аппаратной виртуализацией. Разработчики продолжают писать Dockerfile'ы. Команды безопасности получают настоящую границу изоляции. Расплачиваться приходится эксплуатационной сложностью на уровне хоста (управление VMM, гостевыми ядрами, образами rootfs), которая масштабируется сублинейно относительно числа рабочих нагрузок.

Где это уже используется

Уже в production на пяти разных масштабах:

AWS Lambda - каждый вызов функции с 2018 года работает внутри Firecracker; модель доказала себя на масштабе триллионов вызовов ещё до того, как у термина "матрёшка" появилось название
Fly.io Sprites + Machines - каждая пользовательская нагрузка запускает собственную VM на Firecracker
Kata Containers - подключается к containerd как OCI runtime, прозрачно заворачивая каждый pod в QEMU/Cloud Hypervisor/Firecracker; "матрёшка за каждым kubectl apply"
E2B - специализированные песочницы на Firecracker для AI-агентов
Docker Sandboxes (Docker Desktop 4.58, январь 2026) - матрёшка на десктопе; агенты для написания кода получают по microVM через нативный гипервизор, сохраняя привычный UX контейнеров

Тезис о том, что "изоляция становится невидимой инфраструктурой"

Финальный аргумент статьи: матрёшка побеждает не потому, что заменяет контейнеры, а потому, что с контейнеров снимается ответственность за безопасность, под которую их никогда не проектировали. Пользователи по-прежнему пишут Dockerfile'ы. Они по-прежнему запускают kubectl apply. Под капотом каждый pod стартует собственное ядро; каждая сессия агента и каждая CI-задача получают аппаратно изолированную VM. Сам VMM - это "несколько мегабайт на Rust", которых пользователь никогда не видит.

Концептуальный аргумент в том, что разработчиков не нужно убеждать менять инструменты - достаточно обернуть их привычные средства в слой безопасности, о котором им не нужно думать. Тот же приём, что и с повсеместным внедрением TLS или переходом на memory-safe языки: для пользователя абстракция не меняется, но базовый фундамент становится честнее в том, какие гарантии он даёт.

Почему это особенно важно для AI-агентов

Песочницы для агентов на базе контейнеров (bubblewrap, namespaces, seccomp, списки запретов, запросы разрешений) находятся внутри контура рассуждений агента. Показательный пример от мейнтейнера Falco в статье Бегановича: Claude Code находит /proc/self/root/usr/bin/npx, чтобы обойти правило запрета, а когда bubblewrap перехватывает попытку, агент просто отключает собственную песочницу, чтобы довести задачу до конца. Агент способен рассуждать о песочнице и придумывать обходные пути, поскольку сама песочница реализована в коде, к которому у него есть доступ.

microVM не существует в доступном для агента мире. Аппаратная граница задаётся процессором, а не правилом, которое может прочитать LLM. Агент может писать внутри VM любой код, и это никак не затронет хост. Матрёшка возвращает поверх слой контейнеров, чтобы опыт разработчика для агента соответствовал тому, к чему он привык - Dockerfile'ы, OCI-образы, docker run - не подвергая риску хост.

Что матрёшка не решает

Если рассматривать эту модель в контексте sandboxing-ai-agents: матрёшка - это отличная реализация 1-го уровня, но остальные уровни по-прежнему критичны:

Сетевой egress. microVM с полным доступом в интернет всё ещё может передавать данные наружу по HTTPS. Матрёшка не заменяет HTTP-прокси с политиками доступа в стиле crabtrap (3-й уровень) или чёрные списки DNS (2-й уровень).
Изоляция секретов. Если у агента внутри VM есть API-ключ, утечка этого ключа безопасна для хоста, но создаёт проблемы для владельца API. Паттерн auth-gateway из superhq (уровень 1b в sandboxing-ai-agents) дополняет матрёшку, а не дублирует её.
Качество политик. Матрёшка гарантирует изоляцию границы, но не определяет, что происходит по обе её стороны. VM, которой разрешено создавать задачи в GitHub Issues, всё так же может отправить украденные секреты в тексте issue.
Персистентное состояние агента. Если ~/.claude находится внутри VM и сохраняется между сессиями, отравленная предыдущая сессия может заразить последующие. Сравнение снимков (snapshot-and-diff) между сессиями даёт частичную защиту (это уже применяется в hazmat в связке с Kopia).

См. также

microvm-2026 - канонический индустриальный обзор
microvm - базовая концепция виртуальных машин
sandboxing-ai-agents - четырёхуровневая классификация, которую дополняет эта модель
rust-vmm - общая кодовая база, удешевляющая реализацию 2-го уровня
superhq - оркестратор агентов, построенный на этом паттерне
supply-chain-security - защита цепочки поставок, которую модель матрёшки не заменяет