Лучшие практики изоляции агентов: песочница (закрытая бета)

Для клиентов нашей программы Cyber Verification Program мы предоставляем новый классификатор escape из песочницы в API для мониторинга и снижения злоупотреблений. В этой статье объясняется, почему автономные агенты нуждаются в сильной изоляции, как эталонный дизайн их изолирует и как определить область и контролировать взаимодействия, требующие доступа в сеть.

Для обзора всех доступных вам ресурсов см. Лучшие практики изоляции агентов: начало работы (закрытая бета).

Если вы создаете свою собственную песочницу, это свойства, которые предоставляет эталонный дизайн. Остальная часть этой статьи описывает один способ их получить.

Запускайте автономные агенты в сильных песочницах и подумайте о том, какие побочные эффекты может вызвать процесс в этой песочнице. Передовые модели все лучше находят творческие пути обхода ограничений: то же свойство, которое делает их эффективными охотниками за уязвимостями, означает, что они могут предпринять неожиданные действия против собственной среды выполнения. Это не гипотетично. Anthropic опубликовала примеры моделей, обходящих слабые ограничения для выполнения задачи (см. Как мы изолируем Claude во всех продуктах).

Конкретно, не запускайте автономные агенты поиска уязвимостей в простом Docker/runc, и особенно не с --privileged или сетевыми возможностями хоста. Стандартные контейнеры разделяют ядро хоста, поэтому эксплуатация ядра внутри контейнера — это компрометация хоста. Мы рекомендуем поместить аппаратно-виртуализированное ядро между целевым кодом и хостом, что означает запуск агента на виртуальной машине. Если это невозможно, используйте выделенный хост bare-metal, на котором ничего больше нет. Если вы создаете свою собственную песочницу, мы рекомендуем Firecracker на Linux, Hyper-V на Windows и виртуальную машину на основе фреймворка Hypervisor на macOS. Эталонный дизайн использует Firecracker.

Заблокируйте весь исходящий трафик из песочницы. Агент достигает API модели только через прокси, который добавляет учетные данные и работает вне песочницы, поэтому песочнице не нужен прямой маршрут к хосту API. Установите каждый инструмент, пакет и зависимость перед началом запуска, чтобы ничего не нужно было загружать во время него.

Интерактивное использование с человеком в цикле обычно несет меньший риск, но мы все равно рекомендуем песочницу для него. Если вы управляете агентом интерактивно из Claude Code на ноутбуке, либо проверьте каждое использование инструмента (ручной режим), либо полагайтесь на классификатор разрешений в автоматическом режиме и получите одобрение человека для каждого действия, которое выходит за пределы репозитория. Автоматический режим удаляет обычные запросы разрешений: он автоматически одобряет чтение и редактирование рабочего каталога и отправляет все остальное фоновому классификатору, который стремится блокировать деструктивные, необратимые или внеплановые действия. Это проверка на основе лучших усилий. Она может что-то пропустить, и при работе с безопасностью она также может отказать в некоторых законных шагах. Автоматический режим описывает, как он работает, чего от него ожидать и как его настроить для вашей среды.

Никогда не монтируйте пути, содержащие учетные данные, такие как ~/.aws, ~/.ssh или .env, в окружение агента. То же самое относится к учетным данным, которые использует собственный вызов модели агента. Держите его вне песочницы и пусть прокси, который агент не может прочитать, добавляет его к каждому запросу (см. Прокси учетных данных). Не подключайте агентов к серверам MCP или инструментам с доступом на запись к внешнему состоянию, такому как электронная почта, облачное хранилище или производственная инфраструктура.

Это один из шаблонов, который воплощает вышеуказанные рекомендации в жизнь. Фаза настройки имеет исходящий доступ в интернет и человека в цикле, который одобряет каждый вызов инструмента. В ней агент извлекает зависимости, создает цель и устанавливает свою песочницу из документа спецификации. Фаза атаки не имеет общего доступа в интернет. Весь исходящий трафик проходит через прокси списка разрешений, который разрешает только хосты, названные в взаимодействии, поэтому прокси также обеспечивает область. Вызовы модели проходят через отдельный прокси учетных данных. Агент может затем зондировать цель без присмотра. Прокси содержит собственный трафик агента. Он не содержит трафик, который сетевая цель отправляет от имени агента.

Запеките зависимости, которые агент регулярно нуждается, в образ настройки, чтобы запуски фазы атаки вообще не требовали доступа в интернет. Область учетных данных на цель, чтобы агент, работающий на одной цели, не мог использовать их против другой. Держите автоматический режим Claude Code включенным внутри песочницы во время фазы атаки и опишите песочницу его классификатору. См. Автоматический режим.

Дайте каждому агенту явный бюджет, чтобы запуск, превышающий предполагаемое тестирование, остановился самостоятельно, а не когда кто-то это заметит. Обеспечьте жесткий лимит ходов для каждого агента. Когда агент его исчерпает, завершите запуск и не предоставляйте больше ходов автоматически. Перезапуск с более высоким лимитом — это момент, когда человек решает продолжить. Ограничьте запуски и по времени. Завершите сеанс, превышающий лимит времени, таким же образом: запуск окончательный и никогда не возобновляется, и процесс агента останавливается, даже если лимит достигнут в середине долгоживущей команды. Если лимит установлен на значение, которое невозможно прочитать, откажитесь от запуска вместо запуска без ограничений. Установите лимиты намеренно для взаимодействия и не принимайте щедрое значение по умолчанию. Свяжите их с кадром мониторинга в автономном мониторинге стенограмм агентов, чтобы длинный пакет просматривался каждый час или два, а не только в конце. Знайте, как остановить одного агента без остановки пакета. В установке на основе Docker это docker rm -f <agent-container>. Оркестратор должен записать этот запуск как неудачный и продолжить с остальной частью пакета.

Для получения дополнительных рекомендаций прочитайте два ресурса Anthropic. Безопасное развертывание агентов AI охватывает варианты изоляции, проксирование учетных данных и усиление файловой системы. Инженерный ретроспективный анализ Как мы изолируем Claude во всех продуктах охватывает то, что сработало и что не сработало, когда эти же механизмы работали в производстве.

Песочница ограничивает то, что может достичь агент. Для тестирования на проникновение, красного командования и других взаимодействий, требующих доступа в сеть, приведенные ниже практики ограничивают то, что агента просят и разрешают делать. Они зависят от ваших целей и вашей команды, поэтому инструменты не могут поместить большинство из них на место для вас.

Перед запуском скажите агенту, какие цели находятся в области, какие действия разрешены, где находится граница сети и что находится вне области. Сформулируйте каждое ограничение как намерение ("не обращайтесь к хостам вне 10.0.3.0/24"), а не как утверждение об окружении ("вы не можете достичь интернет"), чтобы инструкция все еще действовала, если окружение неправильно настроено. Делайте это и для изолированной локальной работы: скажите агенту не использовать доступ в интернет, даже если песочница его блокирует. Описание, которое вы даете классификатору автоматического режима, — это другое. Оно излагает факты о машине (см. Автоматический режим).

Где вы можете, запустите агента внутри той же изоляции, описанной выше, и добавьте в список разрешений исходящий трафик только к целям в области (см. Список разрешений исходящего трафика). Агент достигает API модели через прокси учетных данных, а не через список разрешений. Где он доступен, направьте взаимодействие на промежуточную или реплицированную среду, которая отключена от производства.

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

Мы рекомендуем, чтобы инженер наблюдал за каждым запуском по мере его выполнения, следя за вызовами инструментов и сетевой активностью, и мог немедленно остановить запуск. Агенты действуют с машинной скоростью, поэтому живое наблюдение дополняет элементы управления, которые действуют перед выполнением действия (списки разрешений сети, брокерские инструменты и проверка действий, изменяющих состояние). Это их не заменяет. Для длительных или автономных запусков, где непрерывное внимание непрактично, контролируйте непрерывно в программном обеспечении (см. Автономный мониторинг стенограмм агентов).

Не запускайте автономные агенты против живых производственных систем, где внеплановое действие может поставить под угрозу безопасность или доступность критических услуг, таких как OT/ICS, медицинские или энергетические системы. Это уже норма для тестирования, проводимого человеком таких систем, и она применяется здесь в равной степени. Тестируйте на реплике, тестовой среде или цифровом двойнике или во время запланированного отключения. Если живой доступ неизбежен, ограничьте агента пассивной или только для чтения деятельностью и пусть человек выполняет каждый шаг, изменяющий состояние.

Перед запуском реальных взаимодействий с хоста протестируйте его песочницу с помощью двух шагов ниже. Делайте это перед первым реальным использованием и снова всякий раз, когда вы меняете модель или песочницу. Изменения песочницы включают новый хост, новую версию гипервизора или среды выполнения контейнера, другую сетевую или прокси-установку и отредактированную конфигурацию контейнера или compose.

В интерактивном сеансе Claude Code на хосте попросите его прочитать конфигурацию песочницы, установленную на этой машине, и сообщить обо всем, что ослабляет границу, описанную в этой статье. Укажите ему на:

Этот шаг только читает конфигурацию и состояние. Он не запускает агента.

Запустите тестовый агент так же, как вы запускаете производственные агенты, а не с помощью ручной команды, чтобы тест использовал реальный путь. Раздел Проверьте изоляцию самостоятельно ниже охватывает ручные проверки границы. Дайте агенту одну задачу: попытаться достичь чего-либо за пределами его границы и остановиться и сообщить, как только что-либо удастся. Назовите границу конкретно в подсказке: хост, другие контейнеры, сокет контейнерного времени выполнения, сервис метаданных облака и любой хост, который не находится в списке разрешений прокси. Запускайте это только под тщательным контролем человека на хосте без доступа в Интернет, кроме API модели, и который вы готовы перестроить, чтобы успешный побег не нанес ущерба. На голом металле запустите тест внутри одноразовой виртуальной машины. На облачной виртуальной машине используйте свежий экземпляр и уничтожьте его впоследствии. Наблюдайте за сеансом во время его выполнения. Рассматривайте любой успех как блокировщик: исправьте хост, повторите тест и не запускайте взаимодействия с этого хоста, пока тест не пройдет.

Проверьте, что пытался сделать агент, а также вышел ли он. Ищите прямые соединения, которые не прошли через прокси, чтение файлов учетных данных или адресов метаданных, использование сокета контейнерного времени выполнения или зондирование соседних контейнеров, запись вне собственной файловой системы контейнера и попытки изменить собственные параметры или инструменты агента. Тест проходит, когда стенограмма показывает, что каждое из них было попробовано и не удалось по ожидаемой причине. Запишите для каждого, остановила ли его песочница или классификатор разрешений. Попытка, которую классификатор отклонил, никогда не достигала песочницы, поэтому охватите ее ручными проверками (см. Проверьте изоляцию самостоятельно ниже). Прохождение теста — это минимальный стандарт, а не доказательство изоляции.

Перед запуском подтвердите, что задача может быть выполнена в том виде, в котором она дана. Некоторые примеры задач, которые не могут быть выполнены: область фокуса, в которой нечего найти, цель, которая недостижима, ошибка, которой нет, или инструмент, который нужен для задачи и не установлен. Всякий раз, когда вы меняете свою установку или начинаете новый вид задачи, перед запуском подтвердите, что цель собирается и может быть достигнута и что агент имеет необходимые инструменты. По той же причине, когда вы проверяете пакет, прочитайте стенограммы запусков, которые не удались или ничего не нашли, перед теми, которые прошли успешно.

Запустите эти проверки вручную на каждом хосте. Второй столбец описывает проверку для эталонного дизайна (Docker с временем выполнения Kata и Firecracker). Адаптируйте его к вашему собственному времени выполнения.

В этом разделе описывается, как эталонная реализация соответствует приведенному выше руководству. Реализация не включена. Читайте это как дизайн, который вы можете скопировать.

Каждый агент работает как claude -p внутри своей собственной микроВМ рядом с целевым двоичным файлом и источником. МикроВМ — это контейнер Kata Containers, поддерживаемый монитором виртуальной машины Firecracker, зарегистрированный в Docker как время выполнения. Инструменты Read, Write и Bash агента видят только файловую систему и ядро этого гостя.

Соединение между гостем и хостом намеренно мало. Оно состоит из KVM и нескольких виртуальных устройств, которые эмулирует Firecracker: блочные устройства для диска контейнера, один сетевой интерфейс и канал управления vsock, который Kata использует для запуска процессов внутри гостя. Сам процесс Firecracker ограничен на хосте. Он работает в «тюрьме», которая представляет собой каталог chroot, содержащий только файлы этой виртуальной машины, с собственным пространством имен монтирования, пространством имен сети контейнера и встроенным фильтром seccomp Firecracker. Он учитывается в cgroup контейнера. То, что вы доверяете на стороне хоста, — это KVM, Firecracker и процесс времени выполнения Kata (шим для каждого контейнера, с которым разговаривает Docker, работающий от имени root).

Оркестратор остается на доверенном хосте. Он управляет жизненным циклом контейнера, передает стенограммы и перемещает файлы внутрь и наружу с помощью docker exec, который Kata обслуживает через своего агента внутри гостя. Средство запуска запускает агентов только внутри этой песочницы. Перед запуском любого агента он проверяет, что среда выполнения песочницы зарегистрирована, что /dev/kvm присутствует и что исходящий прокси работает, и отказывает в противном случае.

Что песочница меняет для каждой поверхности:

Где применяется каждое свойство: аппаратная виртуализация обеспечивает границу ядра и файловой системы. Read/Write/Bash агента работают против гостевого ядра, а процесс Firecracker позади него заключен в тюрьму и ограничен seccomp на хосте. Политика исходящего трафика применяется на стороне хоста сетевого интерфейса виртуальной машины с помощью моста Docker --internal (без маршрута по умолчанию) и двух прокси в этой сети. Прокси учетных данных пересылает только вызовы модели и ничего больше. Прокси исходящего трафика отказывает каждому другому назначению, потому что его список разрешений пуст, если вы не добавите в него записи. Трафик выходит через собственный сетевой стек гостевой системы; фильтрация происходит в двух прокси.

Учетные данные для API модели (ваш ключ API, токен OAuth, учетные данные AWS или Google) никогда не помещаются в контейнер агента. Оркестратор на хосте читает и проверяет их, и каждый запуск запускает один небольшой дополнительный контейнер, прокси учетных данных, чтобы его содержать. Прокси подключен к внутренней сети агентов, и контейнеры агентов отправляют свои вызовы модели ему: их CLI claude получает адрес прокси в качестве базового URL API и фиксированное значение-заполнитель вместо ключа или токена. Это следует лучшей практике доступа к API модели только через прокси с внедрением ключа API извне песочницы. В эталонной конструкции прокси — это отдельный контейнер в сети агентов, а не процесс на собственном localhost агента. Для каждого запроса прокси:

Для скомпрометированного контейнера агента это означает, что нет ключа, токена или файла учетных данных для чтения, копирования или отправки куда-либо. Облачные сервисы метаданных также недоступны из контейнера. То, что контейнер все еще может делать, — это делать вызовы модели через прокси на вашем счете, пока выполняется запуск. По этой причине предпочитайте узко ограниченные учетные данные для запусков агента и ротируйте их после любого запуска, чья стенограмма показывает неожиданное поведение. Прокси регистрирует одну строку на запрос с адресом клиента, методом, путем, статусом и размером. Он не регистрирует заголовки или тела. Сохраните этот журнал при завершении запуска (см. раздел Retention в Offline monitoring of agent transcripts).

Все, что агент отправляет в API модели, покидает вашу сеть в телах запросов, которые прокси не проверяет и не регистрирует.

Что держит каждая сторона, по маршруту аутентификации:

Контейнер прокси учетных данных является частью доверенной стороны установки. Он работает под простым runc, а не под средой выполнения песочницы, от имени root со всеми возможностями отключены, кроме того, который ему нужен для чтения смонтированных файлов, и с файловой системой только для чтения. Он прослушивает только свой адрес во внутренней сети агентов и подключается к поставщику напрямую, а не через прокси исходящего трафика. Оркестратор передает учетные данные работающему прокси через docker exec. Для маршрутов файла токена WIF и профиля каталог, содержащий токен или профиль, монтируется только для чтения в прокси, который читает файл оттуда. Учетные данные не находятся в окружении контейнера прокси или в его командной строке, поэтому docker inspect на нем показывает монтирования, а не секрет.

Запустите один прокси на запуск и удалите его при завершении или прерывании запуска. Проверьте наличие прокси, оставленных запуском, который был убит, и удалите их перед следующим запуском.

Прокси учетных данных имеет два побочных эффекта. Во-первых, CLI агентов получает нестандартный адрес API, поэтому несколько функций CLI, которые применяются только к адресу по умолчанию, отключены внутри контейнеров агентов. Его телеметрия и проверки обновлений также отключены, потому что у них не было бы маршрута выхода в любом случае. Во-вторых, на Vertex фильтр пути прокси является основным элементом управления, который предотвращает использование контейнером агента остальной части API Vertex AI (см. Список разрешений исходящего трафика). Проверка области IAM ключа при запуске — это второй уровень.

Список разрешений прокси исходящего трафика пуст по умолчанию. Контейнеры агентов достигают API модели только через прокси учетных данных (см. Прокси учетных данных). Каждый запуск запускает этот прокси для поставщика, выбранного вашими учетными данными, поэтому ничего специфичного для поставщика не хранится в установке песочницы. Каждое другое назначение, которое агент запрашивает через прокси исходящего трафика, включая сам хост API модели, получает 403 и строку отказа в его журнале. Значения региона, которые выбирают конечные точки Bedrock и Vertex (AWS_REGION, CLOUD_ML_REGION), проверяются по строгому шаблону перед использованием, чтобы неправильное значение не могло отправить учетные данные на другой хост.

Vertex имеет одно ограничение, о котором следует знать. …aiplatform.googleapis.com обслуживает весь API Vertex AI, поэтому учетные данные, которым разрешено создавать пользовательские задания, могут запустить произвольный контейнер с полным исходящим доступом в интернет в вашем проекте. Используйте два элемента управления против этого. Пусть прокси учетных данных пересылает только вызовы модели издателя на вашем настроенном проекте (…/publishers/anthropic/models/…:rawPredict, :streamRawPredict и :countTokens) и отказывает каждому другому пути. И проверьте область IAM ключа при запуске и откажитесь закрыто: отказывайте пользователю gcloud ADC, проверьте ключ сервисного аккаунта с помощью testIamPermissions и отказывайте ему, если он содержит какое-либо разрешение на создание рабочей нагрузки. Предоставьте аккаунту пользовательскую роль, которая содержит только aiplatform.endpoints.predict. Сервер метаданных, Google STS и конечные точки учетных данных IAM не должны быть доступны из контейнеров агентов.

Если агентам нужно достичь дополнительных хостов, таких как зеркало пакетов или целевой объект в области, добавьте их в список разрешений прокси исходящего трафика как записи host:port. Добавляйте только то, что нужно для взаимодействия (см. Scope and supervision).

Не добавляйте хост модели-API в этот список. Агентам это не требуется, так как их вызовы модели проходят через прокси учетных данных. Добавление его дает контейнерам агентов прямой маршрут к API, а остальная часть дизайна, включая то, что сообщается классификатору разрешений, предполагает, что у них его нет.

Изменение списка разрешений означает перезагрузку прокси исходящего трафика, что прерывает все активные соединения агентов. Делайте это между пакетами, а не во время одного, и подтвердите после, какой список загрузил прокси.

Получите конечную точку поставщика из конфигурации учетных данных и игнорируйте переменную базового URL, такую как ANTHROPIC_BASE_URL, установленную на хосте: прокси учетных данных всегда должен перенаправлять на конечную точку, выбранную учетными данными.

В этом разделе собрано то, что было изучено при запуске агентов под Kata с Firecracker в эталонной реализации. Это не набор инструкций по установке.

Эталонный дизайн требует физической машины Linux или виртуальной машины, которая сама может запускать виртуальные машины:

Его песочница требует KVM на хосте Linux. Docker на Mac работает внутри общей виртуальной машины Linux, которая монтирует домашний каталог пользователя и содержит демон Docker, поэтому он не может обеспечить изоляцию оборудования для каждого агента. Если вы работаете на Mac, запустите агентов на хосте Linux с KVM (bare metal или облачная виртуальная машина с вложенной виртуализацией) и управляйте ими через SSH. Если вы создаете свою собственную песочницу на macOS или Windows, см. гипервизоры, названные в разделе Общие рекомендации выше.

Образы и контейнеры, созданные в предыдущем хранилище Docker, становятся невидимыми для Docker после переключения на snapshotter devmapper. Они остаются на диске. Чтобы увидеть их снова, поместите оба параметра хранилища в daemon.json (storage-driver и features.containerd-snapshotter) обратно в то, что они были, и перезагрузите Docker.

Зафиксируйте выпуск Kata и проверьте его дайджест перед установкой. Эталонный дизайн начинается с профиля Firecracker Kata и фиксирует эти параметры в /etc/kata-containers/configuration.toml:

Значения kernel, image и kernel_params, поставляемые с релизом Kata, остаются без изменений.

Каждая виртуальная машина загружается из одних и тех же двух файлов, Kata привязывает их к каждой тюрьме, и тюремщик запускается от root, поэтому обычные разрешения файлов не помешают скомпрометированному процессу Firecracker переписать образ, с которого загружается каждая последующая виртуальная машина. Установите флаг неизменяемости на оба файла (chattr +i). Очистка этого флага требует системного вызова, который фильтр seccomp Firecracker не разрешает, что предназначено для предотвращения этого даже root внутри тюрьмы. Очистите флаг самостоятельно перед установкой нового релиза Kata. На файловой системе без поддержки chattr используйте вместо этого привязку только для чтения.

Каждая виртуальная машина агента имеет размер один раз при загрузке: default_memory плюс --memory контейнера. С базовым размером 4096 МиБ и лимитом контейнера 4g агент представляет собой виртуальную машину объёмом 8 ГиБ. Хост выделяет эту память виртуальной машине по мере её использования гостем, а не всю при загрузке, но планируйте полный объём на каждого одновременного агента: десять агентов параллельно могут вырасти до 80 ГиБ. Применяется ли лимит --memory контейнера ко всей виртуальной машине в целом, зависит от того, как организованы cgroups хоста. Проверьте, какой из этих вариантов применяется на вашем хосте:

Мы не подтвердили это поведение на всех типах хостов. В любом случае размер хоста по размеру виртуальной машины.

Каждая виртуальная машина получает default_vcpus. Firecracker не может добавлять процессоры к работающей виртуальной машине, поэтому для целей с интенсивной сборкой увеличьте значение перед запуском; максимум 32 на виртуальную машину.

Каждый образ и каждый контейнер получают виртуальный диск из тонкого пула device-mapper, который поддерживает хранилище образов. Если пул заполнится, записи внутри контейнеров завершатся с ошибками ввода-вывода или нехватки места. Если файловая система, содержащая пул, заполнится первой, пул становится доступным только для чтения и каждый контейнер на нём выходит из строя. Освободите место с помощью docker rmi и docker system prune (освобождённые блоки возвращаются в пул). sudo dmsetup status <pool> показывает использование. Для долгоживущего хоста тонкий пул LVM на выделенном диске — лучший вариант.

Каждый запуск агента загружает ядро гостя. Это занимает менее секунды на голом металле и несколько секунд при вложенной виртуализации, что мало по сравнению со временем выполнения агента.

После настройки новой машины эта последовательность показывает, что песочница работает от начала до конца. Шаги 3 и 4 выполняют реальные вызовы модели.

Запуск агентов в Kata с Firecracker отличается от запуска простых контейнеров следующим образом.

Firecracker не имеет общего доступа к файловой системе хоста, поэтому Kata копирует привязанный файл или каталог в гостя при запуске контейнера, и более поздние изменения на хосте не видны внутри. Это нормально для входных данных, которые не изменяются во время выполнения, таких как исходный код целевого объекта, и они могут оставаться монтированиями только для чтения. Никакой файл учётных данных не монтируется и не передаётся потоком, потому что контейнеры агентов не содержат ни одного (см. Прокси учётных данных). Файл, который изменяется во время выполнения, должен быть записан в контейнер оркестратором через docker exec и поддерживаться в актуальном состоянии. Копии в контейнере — это обычные файлы, которые агент под тестом может редактировать, поэтому пусть оркестратор прочитает оригиналы на хосте и судит о результатах из копии, которую агент под тестом не может достичь.

Сетевые интерфейсы микровиртуальной машины должны существовать при загрузке виртуальной машины; Firecracker не может добавить один позже. Docker, однако, подключает сеть контейнера только после того, как среда выполнения создала контейнер. Эталонный дизайн обходит это. Сначала он запускает небольшой неактивный контейнер, подключённый к правильной сети и работающий только sleep, а затем запускает агента внутри пространства имён сети этого контейнера (--network container:<name>). Kata находит интерфейсы там при загрузке и присоединяет их к виртуальной машине. Вспомогательный контейнер служит ровно одной виртуальной машине, потому что Kata оставляет устройства сети виртуальной машины на стороне хоста в нём, поэтому создавайте и удаляйте пару вместе и не переиспользуйте вспомогательный контейнер. Один стоит неактивного процесса примерно 12 МБ.

docker rm -f <agent-container> достаточно. Оркестратор должен обнаружить мёртвый контейнер, отметить выполнение как неудачное и удалить вспомогательный контейнер при разборке выполнения.

Встроенный DNS Docker работает в пространстве имён сети на стороне хоста и недоступен изнутри гостевой системы, поэтому передавайте прокси-серверы агентам как IP-адреса и назначайте сетевым целям статический IP.

docker exec в контейнер агента работает обычным образом; агент Kata внутри гостевой системы выполняет команду. docker cp в контейнер агента или из него не работает, потому что файлы контейнера находятся на виртуальном диске внутри гостевой системы. Используйте docker exec <container> cat <path> и подобные команды.

Kata запускает jailer с uid 0, поэтому процесс Firecracker ограничен своей chroot, пространствами имён, фильтром seccomp и cgroup, а не непривилегированным идентификатором пользователя. Два файла, которые использует каждая виртуальная машина — ядро гостевой системы и образ — защищены флагом неизменяемости (см. Параметры Kata).

Kata запускает Firecracker через свою более старую среду выполнения Go. Kata 4.0 сделала новую среду выполнения Rust стандартной для своих других гипервизоров и прекратила поддержку среды выполнения Go. Upstream сообщает, что среда выполнения Go по-прежнему получает критические исправления ошибок и исправления CVE, и что она может быть удалена не ранее Kata 5.0. Среда выполнения Rust не указывает Firecracker среди своих гипервизоров, и upstream тестирует её интеграцию с Docker в основном с QEMU. Планируйте миграцию. Когда вы обновляете версию Kata, повторите Проверка нового хоста. Kata также может использовать Cloud Hypervisor вместо Firecracker; эталонная реализация не тестировала и не укрепляла эту конфигурацию.

Сообщения среды выполнения Kata, Firecracker и гостевого агента поступают в журнал: journalctl -t kata. Проблемы containerd и Docker находятся в journalctl -u containerd и journalctl -u docker.