Docker MCP понимают двояко: как каталог готовых серверов MCP, запускаемых в контейнерах, и как доступ агента к самим контейнерам, чтобы он смотрел состояние, читал журналы и, возможно, запускал и останавливал сервисы. Во втором случае цена ошибки высока, поэтому порядок такой: составить перечень разрешённых действий, выдать минимальные права, проверить всё на отдельном окружении и только потом думать о рабочем сервере. Написание собственного сервера MCP оставлено за скобками.
Два смысла
Docker MCP означает либо запуск серверов MCP внутри контейнеров, либо управление контейнерами через MCP. Первое снижает риск изоляцией, второе наоборот требует жёстких границ действий агента.
Справка Docker описывает каталог и набор инструментов для MCP: подобранные серверы поставляются контейнерными образами с версиями, сведениями о происхождении и обновлениями безопасности, а клиенты вроде редакторов и агентов подключаются к ним централизованно. Идея в том, чтобы вместо отдельной установки каждого сервера на машину запускать его изолированно. Это один смысл. Второй смысл касается доступа агента к самому Docker: перечислить контейнеры, прочитать журналы, проверить состояние.
Разница между сценариями принципиальна, и в разговорах она часто теряется: кто-то слышит «безопасный каталог» и распространяет это ощущение на любое подключение агента к Docker. Первое снижает риск от чужого кода, второе добавляет полномочия агента. Разбирайте их раздельно и принимайте решение отдельно по каждому.
| Сценарий | Что получает агент | Главный риск |
|---|---|---|
| Сервер MCP в контейнере | Инструменты сервера, изолированные от машины | Ненадёжный образ и лишние секреты внутри |
| Агент читает состояние контейнеров | Список, журналы, статус | Утечка чувствительных данных из журналов |
| Агент управляет контейнерами | Запуск, остановка, перезапуск, удаление | Остановка рабочих сервисов и потеря данных |
| Агент получает доступ к сокету Docker | Практически полный контроль над хостом | Захват машины целиком |
Общую идею протокола и зачем он бизнесу мы объясняли в статье MCP: что это и зачем бизнесу, а о том, как описываются инструменты сервера, читайте в материале MCP tools: что такое инструменты сервера и как их описывать.
Каталог и профили
В описании Docker выделены три понятия. Каталог — подборка проверенных серверов в виде контейнерных образов; организации могут вести и собственные каталоги с утверждёнными серверами. Профиль — именованный набор серверов для проекта, куда входят как контейнерные серверы из каталога, так и удалённые. Шлюз MCP Gateway маршрутизирует запросы к нужному серверу, а клиенты вроде Claude Code, Cursor и Zed подключаются через него. По справке, шлюз входит в корпоративный пакет управления ИИ от Docker и доступен по приглашению через отдел продаж Docker, поэтому его наличие проверяйте до планов. Для компании самое ценное то, что набор допущенных серверов превращается в управляемый список.
Практическая проверка каждого образа начинается с вопроса, кто его публикует и поддерживает. Образ от поставщика с историей и обновлениями безопасности заслуживает больше доверия, чем безымянная сборка. Но и в первом случае образ глух к вашим правилам, поэтому ограничения вы задаёте сами через права и сетевые настройки.
- Заведите профиль под каждый проект и включайте в него только нужные серверы.
- Для каждого сервера запишите источник образа, версию и автора, как для любого стороннего программного обеспечения.
- Секреты передавайте серверам минимально и по отдельности, чтобы утечка одного оставляла остальное закрытым.
- Обновления образов принимайте после проверки, автоматическое обновление на рабочих машинах отключите.
- Список допущенных серверов храните в общем документе и пересматривайте раз в квартал.
Изоляция в контейнере защищает машину от самого сервера, но бессильна против действий, которые сервер выполняет по вашим поручениям: если он умеет писать в базу или отправлять письма, он будет это делать. Порядок допуска серверов по доступам описан в статье MCP OAuth: доступ, токены и отзыв прав.
Перечень действий
Если агент работает с самими контейнерами, начните с перечня разрешённых действий и расширяйте его осторожно, по ступеням. Каждая ступень требует отдельного решения и теста.
Ступени удобно оформить таблицей: действие, ступень допуска, кто утверждает, как проверяется. Тогда любой вопрос «а можно ли агенту перезапускать сервис» решается ссылкой на строку вместо спора. Таблица хранится рядом с реестром допусков и меняется только через ревью.
- Первая ступень, только чтение: список контейнеров и образов, статус, потребление ресурсов.
- Вторая ступень, чтение журналов: допустимо при условии, что журналы очищены от секретов и персональных данных.
- Третья ступень, управление отдельными тестовыми контейнерами: запуск и остановка в изолированной среде.
- Четвёртая ступень, управление рабочими сервисами: только с подтверждением человека на каждое действие.
- Всегда запрещено: удаление томов с данными, запуск привилегированных контейнеров, монтирование корня хоста, доступ к сокету Docker.
Сокет Docker заслуживает отдельного предупреждения. Доступ к нему равносилен практически полному контролю над машиной, поэтому передавать его агенту нельзя. Вместо сокета выдавайте доступ через ограниченный интерфейс, который поддерживает только перечисленные действия. Подобная логика прав описана в статье Безопасность ИИ-агентов: права, секреты и проверка.
Тест в отдельной среде
Тест выполняется там, где ошибка обходится бесплатно: на отдельной машине или виртуальной среде с тестовыми контейнерами и без рабочих данных.
Отдельная среда может быть очень скромной. Подходит небольшая виртуальная машина, которую можно создать за минуты и удалить после теста, и главное требование к ней одно: никаких путей к рабочим данным и рабочей сети. Если такой среды нет, откладывайте допуск, но тест на рабочей машине с надеждой на удачу исключён.
- Поднимите отдельное окружение: виртуальная машина или отдельный сервер без доступа к рабочей сети.
- Запустите в нём несколько тестовых контейнеров с безобидным содержимым.
- Подключите сервер MCP с самым узким набором действий и проверьте, что чтение работает.
- Попросите агента выполнить запрещённые действия и убедитесь, что они блокируются и остаются невыполненными.
- Проверьте журналы на утечки: найдите в них тестовые секреты и убедитесь, что они скрыты или отсутствуют.
- Проверьте поведение при ошибках: недоступный контейнер, зависший запрос, неверное имя.
- Запишите результаты и решение о допуске, расширяйте перечень действий по одной ступени.
Тест запретов важнее теста возможностей: полезно знать и возможности агента, и то, что ему удаётся обойти. Примеры безопасного запуска контейнерных сервисов для моделей есть в статьях Ollama Docker: локальный сервер, модель и хранение данных и vLLM Docker: контейнер, модель и проверка endpoint.
Какие действия с контейнерами вы хотели бы поручить агенту в первую очередь?
Права и отзыв
Тест закрывает допуск лишь на бумаге. Нужно знать, кто может отозвать права агента и как быстро это делается, прежде чем что-то пойдёт неверно.
Агент получает доступ к рабочим контейнерам только после успешного теста в отдельной среде и записи в реестре. Любое действие, меняющее состояние рабочего сервиса, выполняется после подтверждения ответственного сотрудника.
- Реестр допусков: какой сервер, какие действия, кем разрешено, дата проверки.
- Журнал действий агента: что запрошено, что выполнено, кто подтвердил.
- Кнопка отключения: описан порядок, как быстро убрать доступ агента.
- Раздельные учётные данные для агента, чтобы его действия отличались от действий людей.
- Повторный тест после обновления сервера, образа или самого Docker.
Если вам нужно спроектировать допуск агентов к инфраструктуре и построить порядок тестирования, поможем в рамках консалтинга по внедрению ИИ. А когда потребуется собственный сервер с нужными вам инструментами, смотрите материал MCP Python: минимальный сервер и тест инструмента и обзор MCP server: свои инструменты для ИИ-агентов.