Тень безопасности: почему Docker недостаточно для AI-агентов и куда двигаться

Когда мы даем AI-агенту возможность писать и исполнять код, мы создаем одну из самых опасных дыр в безопасности современной инфраструктуры. Стандартный ответ «мы запускаем это в Docker-контейнере» сегодня является распиской в непонимании того, как работают LLM-агенты и как устроено ядро Linux.

1. Иллюзия изоляции: проблема Shared Kernel

Основная проблема Docker и Kubernetes заключается в том, что они используют общие ресурсы ядра (Shared Kernel). Контейнер — это не виртуальная машина, а процесс с ограниченным набором прав, изолированный с помощью namespaces и cgroups. Однако интерфейс взаимодействия между процессом и ядром — системные вызовы (syscalls) — остается общим.

Для обычного микросервиса это не проблема, так как код статичен и проверен. Для AI-агента, который генерирует код на лету, это катастрофа. Модель может случайно или намеренно создать код, который эксплуатирует уязвимость в одном из сотен syscall-ов ядра Linux. Если злоумышленнику или «галлюцинирующему» агенту удается выполнить Kernel Escape (побег из ядра), он получает доступ к хосту с привилегиями root. В мире, где агент имеет доступ к ключам API, базам данных и внутренним сетям, один успешный syscall-эксплойт означает полную компрометацию всей инфраструктуры.

2. gVisor: Попытка создать «прослойку»

Google предложил решение в виде gVisor. Основная идея здесь в том, чтобы перенести обработку системных вызовов из пространства ядра в пространство пользователя. gVisor предоставляет так называемый Sentry — ядро в пространстве пользователя, которое перехватывает syscall-ы приложения и переводит их в ограниченный набор вызовов к реальному ядру Linux.

С точки зрения безопасности это огромный скачок: поверхность атаки на реальное ядро сокращается в десятки раз. Однако здесь возникает проблема производительности. Каждый системный вызов теперь проходит через дополнительную прослойку, что создает значительный оверхед, особенно в I/O операциях. Для агента, который делает много мелких запросов к файловой системе или сети, gVisor может замедлить выполнение в 2-3 раза.

3. Firecracker и MicroVM: Золотой стандарт изоляции

Если gVisor пытается «фильтровать» вызовы, то Firecracker (разработка AWS) идет другим путем — он создает полноценную, но максимально облегченную виртуальную машину (MicroVM). Firecracker использует KVM (Kernel-based Virtual Machine), чтобы обеспечить аппаратную изоляцию. Каждый агент запускается в собственной MicroVM со своим собственным минималистичным ядром Linux.

Это решает проблему Shared Kernel: даже если агент «взломает» свое ядро, он останется запертым внутри виртуальной машины. Побег из MicroVM в хост-систему на порядки сложнее и требует эксплойтов уровня гипервизора, что в разы реже встречается на практике.

Технический trade-off: Главный минус MicroVM — время холодного старта. Хотя Firecracker оптимизирован до невероятных 100-150 мс, это все равно медленнее, чем запуск Docker-контейнера. Кроме всего, управление жизненным циклом тысяч микро-VM требует сложной оркестрации ресурсов памяти и CPU на хосте.

4. WASM: Безопасность на уровне способностей (Capabilities)

Третий путь — WebAssembly (WASM). В отличие от Docker или MicroVM, WASM не пытается эмулировать ОС. Это виртуальная машина с линейной памятью, где код по умолчанию не имеет доступа ни к чему внешнему. Доступ к сети или файлам предоставляется через модель способностей (capability-based security) — например, через стандарт WASI.

Это идеальный вариант для «чистых вычислений». Если агенту нужно посчитать формулу или обработать JSON, WASM — самый быстрый и безопасный вариант. Но как только агенту требуется полноценная среда исполнения (библиотеки Python, работа с сокетами), WASM становится слишком ограниченным. Тем не менее, архитектурный тренд ведет к гибридным схемам: простые задачи в WASM, сложные — в MicroVM.

5. Сравнительная архитектурная матрица

При выборе среды исполнения кода для агентов следует опираться на следующие метрики:

6. Векторы атак и реальность «побега»

Почему мы так паникуем по поводу Docker? Рассмотрим типовой сценарий. Агент генерирует код, который использует уязвимость в `io_uring` или `netlink` в ядре Linux. В обычном контейнере этот вызов идет напрямую в ядро хоста. Если эксплойт работает, агент получает root-права на физической машине. В системе с Firecracker тот же самый запрос упрется в виртуальное ядро MicroVM. Даже если он «уронит» это ядро, он не выйдет за пределы выделенной ему области памяти, контролируемой гипервизором KVM.

Вывод

Запуск кода от LLM в обычном Docker — это техническая халатность. В промышленном контуре единственно приемлемым решением является использование MicroVM (Firecracker) или, как минимум, gVisor с жестко настроенными egress-фильтрами. Будущее за гибридной моделью: WASM для быстрых проверок и MicroVM для полноценных сессий исполнения.