Слепая зона Docker: один хост, два совершенно разных действия
Docker отлично справляется с изоляцией процессов, однако остается фундаментальная слепая зона: он не может распознать намерение сетевых запросов. Базовый список разрешенных сетевых подключений (allowlist) рассматривает любое исходящее соединение с GitHub как идентичный трафик, независимо от действия на уровне приложения, которое пытается совершить агент.
Представьте агента, хранящего токен GitHub внутри контейнера Docker. Для контейнера запрос на чтение данных репозитория (GET) и запрос на создание issue (POST) выглядят как эквивалентный трафик, направленный к одному и тому же сервису. Механизму обеспечения безопасности Docker на уровнях 3/4 не хватает семантического понимания, чтобы различить эти кардинально разные операции, что создает критический пробел в безопасности.
Контейнеры остаются бесценными для инкапсуляции сред выполнения и обеспечения надежных уровней безопасности. Ограничение возникает при опоре исключительно на сетевую доступность как арбитра разрешенных действий. Эта традиционная модель задает вопрос: «Может ли агент достичь этой конечной точки?». Более важный вопрос: «Что агенту разрешено делать с этим доступом?», остается без ответа.
Эта слепая зона подчеркивает необходимость более гранулярного, учитывающего специфику приложений подхода к песочницам (sandboxing). Хотя Docker успешно изолирует процесс агента от хоста, он не может выразить тонкие политики уровня приложения, которые регулируют конкретные действия API, оставляя критические операции уязвимыми.
Тест с curl, который выявляет разницу
Традиционная сетевая безопасность спрашивает, может ли агент достичь цели; более глубокий вопрос заключается в том, какие действия он может предпринять после подключения. Чтобы проиллюстрировать это критическое различие, рассмотрим тест curl к API GitHub изнутри контейнера. Изначально запрос отклоняется по умолчанию.
Затем обновление политики разрешает доступ только для чтения к API GitHub. Это изменение, примененное без перезапуска контейнера или агента, немедленно позволяет команде curl получать данные. Тот же инструмент, с того же хоста, теперь успешно взаимодействует с API.
Однако следующий тест является решающим: попытка выполнить POST-запрос для создания нового issue в GitHub. Несмотря на использование идентичной команды curl и обращение к той же конечной точке API, эта операция записи отклоняется. Политика явно разрешала чтение, а не запись.
Это демонстрирует силу инспекции на уровне приложений. В отличие от базового правила IP-и-порта, которое видит весь трафик к GitHub как недифференцированный, продвинутые песочницы, такие как NVIDIA OpenShell, могут применять правила на основе HTTP-методов (GET против POST) и конкретных путей API. Эта семантическая осведомленность гарантирует, что даже при наличии валидного токена агент ограничен своими целевыми возможностями, что предотвращает непреднамеренные или вредоносные действия.
OpenShell переносит барьер безопасности в среду выполнения (runtime)
NVIDIA OpenShell смещает периметр безопасности с хоста контейнера в среду выполнения агента. Эта песочница с открытым исходным кодом, выпущенная под лицензией Apache 2.0, не является заменой Docker; вместо этого она предоставляет уровень принудительного применения политик специально для автономных AI-агентов. OpenShell контролирует действия агента на гораздо более тонком уровне, чем традиционные списки разрешенных сетевых подключений.
Операторы определяют декларативные политики с помощью YAML, которые OpenShell компилирует в правила Open Policy Agent (OPA/Rego). Эти политики обеспечивают контроль с учетом HTTP, позволяя вводить гранулярные ограничения на методы (например, GET против POST), конкретные пути и разрешенные бинарные файлы, такие как /usr/bin/curl. Важно отметить, что изменения политик вступают в силу без перезапуска работающего агента, как показано в рабочем процессе.
Дизайн OpenShell выходит за рамки сетевого трафика. Он включает многоуровневую изоляцию, используя Linux Landlock LSM и профили seccomp для ограничений файловой системы и процессов. Это предотвращает повышение привилегий и несанкционированные системные вызовы. Брокер учетных данных дополнительно повышает безопасность, предотвращая прямое хранение API-секретов агентами; реальные токены внедряются только тогда, когда запросы соответствуют разрешенным правилам исходящего трафика, что снижает риски инъекций промптов.
Для тех, кто интересуется базовыми механизмами и дополнительными деталями реализации, проект доступен здесь: NVIDIA OpenShell: Runtime for Autonomous AI Agents. Этот комплексный подход направлен на ограничение агентов и определение того, что им разрешено делать, а не только того, к чему они могут получить доступ.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Режим «только чтение» не избавляет от рисков: знайте границы
Даже при наличии детального контроля доступ только для чтения не является полностью безопасным. Политики должны учитывать не только HTTP-методы, так как GET-запросы все еще могут использоваться для эксфильтрации данных через строки запросов или заголовки. Строгие правила могут потребовать ограничения конкретных путей, параметров и разрешенных схем, а не просто блокировки операций POST или DELETE.
Операционные ограничения также требуют внимания. Пробелы в политиках могут возникнуть из-за автоматического одобрения неизвестных конечных точек или игнорирования сложных протоколов, таких как «сырые» WebSockets или GraphQL, которые традиционные уровни обеспечения безопасности могут с трудом анализировать. Супервизор NVIDIA OpenShell проксирует и инспектирует HTTP-трафик, компилируя декларативные YAML-политики в правила Open Policy Agent (OPA/Rego).
Рассматривайте OpenShell как один из критических уровней в стратегии эшелонированной защиты (defense-in-depth). Тестируйте политики на реалистичных сценариях инъекций промптов, минимизируйте учетные данные, к которым агент может получить доступ, и проверяйте, что именно инспектирует среда выполнения. Агенты внутри песочницы не хранят API-секреты напрямую; вместо этого реальные токены внедряются извне вышестоящим шлюзом только тогда, когда запросы соответствуют разрешенным правилам исходящего трафика.
Для получения более глубоких знаний и информации о реализации изучите репозиторий OpenShell на GitHub и подробную документацию NVIDIA. OpenShell также интегрируется с Linux Landlock LSM и профилями seccomp для контроля файловой системы и процессов, предотвращая повышение привилегий и несанкционированные системные вызовы.
Часто задаваемые вопросы
Почему Docker сам по себе недостаточен для защиты ИИ-агента?
Docker изолирует процессы, но обычные сетевые правила, как правило, разрешают или блокируют соединения по пункту назначения, а не по действию API, которое выполняет агент.
Что добавляет NVIDIA OpenShell?
OpenShell — это среда выполнения с открытым исходным кодом, предназначенная для применения политик, ориентированных на агентов, включая контроль над HTTP-методами и пунктами назначения.
Может ли OpenShell разрешить чтение из GitHub, блокируя запись?
Его политики могут различать разрешенные запросы на чтение и запрещенные запросы на запись, такие как POST-запрос для создания тикета.
Исключает ли API-доступ «только для чтения» риск эксфильтрации данных?
Нет. Строки запросов, заголовки, неподдерживаемые протоколы или чрезмерно разрешительные правила все еще могут создавать риски и требуют тщательной разработки политик.