Контейнер или 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 от начала до конца, а что ИИ-агентам на самом деле нужно от инфраструктуры рассматривает изоляцию как одно из нескольких требований.