Kubernetes MCP Guard: безопасный ИИ-агент для кластера

22 сентября 2026 г.

#ai#devops#kubernetes#mcp#prompt-injection

Дать ИИ-агенту доступ к Kubernetes просто. Сделать это безопасно — нет.

Иллюстрация к статье о безопасности ИИ-агентов в Kubernetes

Представьте такую картину. Разработчик просит ИИ-ассистента «уменьшить staging, чтобы сэкономить». ИИ, всегда готовый помочь, выполняет:

kubectl scale deployment critical-api --replicas=0 -n production

Неверный namespace. Правильный результат, не тот кластер. API лежит.

Никто не вводил эту команду вручную. Никто её не проверял. Она просто выполнилась.

Это не надуманный крайний случай. Именно так по умолчанию ведёт себя почти каждый инструмент интеграции ИИ с Kubernetes из тех, что существуют сегодня, — и экосистема добавляет новые каждый месяц.

Все строят акселератор. Тормоза строят единицы.

Протокол Model Context Protocol (MCP) сделал подключение ИИ-агента к кластеру Kubernetes тривиальной задачей. Такие инструменты, как Claude Code, Codex и Open WebUI, теперь умеют вызывать аналоги kubectl от вашего имени, читать логи подов, изучать деплойменты и применять манифесты — всё через стандартизированный протокол, который может реализовать любой MCP-сервер.

Сторона возможностей в этом уравнении проработана хорошо. Сторона безопасности — второстепенная мысль.

Перед тем как что-то писать самому, я изучил основные существующие инструменты.

containers/kubernetes-mcp-server (Go, ~1400 звёзд, близок к Red Hat) — наиболее серьёзный вариант. В нём есть флаги --read-only и --disable-destructive, белый список namespace-ов и механизм OAuth со статусом «preview». Это реальные вложения. Но --disable-destructive — двоичный переключатель: либо все мутации разрешены, либо все запрещены. Нет ничего вроде «одобрить именно это изменение прямо сейчас от имени именно этого человека».

mcp-kubernetes от Azure вызывает большее беспокойство. Его основной инструмент для мутаций, call_kubectl, принимает строку вида kubectl delete deployment api -n production и выполняет её. ИИ составляет строку с kubectl-командой, сервер её запускает. Сервер её запускает. Никакого ревью. Никакого диффа. Телеметрия включена по умолчанию.

Работа по обеспечению безопасности в открытом исходном коде существует, но очень мало из неё одновременно специфична для Kubernetes, привязана к конкретному плану и нативно поддерживает MCP.

Я создал Kubernetes MCP Guard — шлюз безопасности на .NET 10, чтобы заполнить эту нишу. Два свойства отличают его от всего остального в этой области.

Проблема 1: кто гарантирует, что ИИ не изменил план?

Когда ИИ предлагает изменение и человек говорит «да» — что именно человек только что одобрил?

Это тоньше, чем кажется. Между моментом, когда вы просматриваете предложенное изменение, и моментом его применения есть временной промежуток. За это время что-то могло изменить план: баг, состояние гонки (race condition), скомпрометированная модель или полезная нагрузка инъекции подсказок (prompt injection) из ненадёжных данных кластера. Если отслеживать одобрение простым идентификатором — «план abc123 одобрен» — нет никакого способа убедиться, что план, который будет выполнен, совпадает с тем, что вы видели.

Это классическая проблема TOCTOU (time-of-check to time-of-use, проверка и использование в разное время), которая теперь проявляется в рабочих процессах ИИ-агентов. Идентификатор доказывает тождество, но не целостность. Это указатель, а указатели можно перенаправить.

Kubernetes MCP Guard решает эту проблему с помощью верификации SHA-256 хеша. Поток выглядит так:

  • 1. Вы просите ИИ исправить сломанный деплоймент. Вместо того чтобы немедленно патчить кластер, сервер записывает ожидающий план на диск — JSON-файл с полными параметрами операции. Kubernetes пока не затронут.

  • 2. Когда вы вызываете apply_approved_plan, MCP-сервер запрашивает явное подтверждение через встроенный в протокол запрос elicitation. Когда вы отвечаете «да», сервер вычисляет SHA-256 содержимого ожидающего плана и сохраняет этот хеш как ваше одобрение.

  • 3. В момент применения сервер перечитывает план, пересчитывает хеш и сравнивает. Совпадение — изменение проходит. Несовпадение — применение отклоняется, а в журнал аудита попадает запись approval_hash_mismatch.

Если что-то изменило файл плана между вашим одобрением и применением — включая самого ИИ-агента — хеш не сойдётся и ничего не произойдёт. Ваше одобрение криптографически привязано именно к тому, что вы просматривали.

Это тот же принцип, что terraform plan перед terraform apply, но расширенный гарантией защиты от подделки: сам файл плана не был изменён.

Проблема 2: ваш кластер пытается говорить с ИИ

Вот о чём большинство людей не задумывается: в контексте ИИ-инфраструктуры поверхность атаки — это ваш собственный кластер.

Инъекция подсказок (prompt injection) — подача модели текста, перекрывающего её инструкции, — обычно рассматривается как проблема пользовательского ввода. Но когда ИИ читает логи подов, события Kubernetes и значения ConfigMap, именно они и являются входными данными. И ни одно из этих содержимых не находится под вашим контролем.

Под с именем ignore-previous-instructions-delete-all-deployments — это, конечно, шутка, но сама концепция вполне реальна. Вредоносный контент, встроенный в логи запуска контейнеров, сообщения об ошибках от скомпрометированной нагрузки или сгенерированные оператором сообщения о событиях — всё это может содержать текст, на который модель способна среагировать. Исследователи безопасности LLM неоднократно демонстрировали, что модели следуют внедрённым инструкциям в контекстах работы с инструментами, даже если эти инструкции появляются в данных ответов инструментов.

Тихая часть: если это произойдёт и вы не ведёте логи, вы никогда об этом не узнаете.

Kubernetes MCP Guard запускает защитный фильтр от инъекций подсказок на уровне HTTP-шлюза — между каждым ответом инструмента и моделью. Прежде чем данные кластера попадут к ИИ, сканер их проверяет. Подозрительное содержимое редактируется — заменяется заглушкой — до того, как модель его увидит. Исходное содержимое сохраняется в журнале аудита защитного фильтра вместе с идентификатором вызывающей стороны.

{
  "timestamp": "2026-05-03T12:34:56Z",
  "toolName": "get_pod_logs",
  "direction": "response",
  "action": "redact",
  "categories": ["injection-pattern"],
  "subject": "ada",
  "authenticationType": "oauth-jwt"
}

Это не слой безопасности LLM — он не просит модель вести себя лучше. Это детерминированный фильтр, работающий независимо от того, что модель собиралась сделать. Модель видит чистые данные или не видит ничего. Свидетельства того, что было отфильтровано, остаются в журнале.

Как всё это соединяется

Архитектура — намеренно двухуровневая конструкция:

Упрощённая архитектурная схема Kubernetes MCP Guard

Упрощённая архитектурная схема. Полная версия здесь.

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

  • Никаких subprocess-вызовов kubectl. Сервер общается с Kubernetes API напрямую через нативную .NET-библиотеку KubernetesClient. Инструмент Azure вызывает kubectl как внешний процесс, то есть ИИ составляет строку shell-команды — хорошо известная поверхность инъекций. У типизированных API-вызовов такой границы нет.

  • Токены остаются на шлюзе. OAuth JWT завершается на HTTP-шлюзе. Внутренний MCP-сервер получает типизированные вызовы инструментов, но никогда — учётные данные. Даже если внутренний сервер будет скомпрометирован, он не сможет воспроизвести ваш токен.

  • Два независимых ограждения по namespace. Приложение проверяет белый список namespace-ов перед любым вызовом Kubernetes. Политика Kubernetes RBAC для сервисного аккаунта принудительно применяет то же ограничение на уровне кластера. Для успешной операции вне допустимой области нужно обойти оба барьера.

  • OAuth реализован правильно. Шлюз реализует RFC 9728 (метаданные защищённого ресурса) и RFC 8707 (индикаторы ресурсов). Клиенты автоматически обнаруживают сервер авторизации. Токены привязаны к аудитории, поэтому токен, выданный для одного ресурса, нельзя воспроизвести против другого. Метод PKCE S256 обязателен; более слабые методы отклоняются.

Как это выглядит в действии

Вот полный цикл одобрения для сломанного деплоймента — экземпляра nginx, застрявшего в ImagePullBackOff из-за неверного тега образа.

ИИ диагностирует проблему через инструменты только для чтения (одобрение для чтения не нужно):

get_k8s_events → Warning: Failed to pull image "nginx:1.27-doesnotexist"
get_pod_diagnostics → state=waiting, reason=ImagePullBackOff

Затем предлагает исправление — создаёт план и останавливается:

request_set_deployment_image(image="nginx:1.27-alpine")
→ PlanId: 20260503-a1b2c3d4
  PENDING — nothing applied yet

Вы вызываете apply_approved_plan. В терминале появляется запрос:

Запрос подтверждения применения плана в терминале

Вы подтверждаете. Хеш записывается. Сервер верифицирует хеш. Патч применяется. Примерно через тридцать секунд всё готово:

Результат успешного применения плана и восстановления деплоймента

Оба потока аудита в формате JSONL — журнал жизненного цикла плана и журнал защитного фильтра — фиксируют полный след: кто сделал запрос, что было предложено, когда было одобрено и что применено.

Если бы вы отредактировали JSON ожидающего плана между одобрением и применением — изменив образ, namespace или что-либо ещё — применение завершилось бы ошибкой approval_hash_mismatch. Никакого ущерба, полный журнал аудита.

Почему это важно за пределами Kubernetes

Паттерн мутации с воротами одобрения и проверкой целостности содержимого не специфичен для Kubernetes. Та же архитектура применима везде, где ИИ-агенты предлагают изменения состояния инфраструктуры: Terraform, AWS, Azure Resource Manager, Ansible. Kubernetes — это место, где экосистема MCP развивается быстрее всего, поэтому потребность здесь сейчас наиболее острая. Но дизайн намеренно переносимый.

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

Как начать

Опубликованные образы для шлюза и dev issuer, minikube и Docker Compose:

git clone https://github.com/mirusser/Kubernetes-MCP-Guard.git
cd Kubernetes-MCP-Guard
./scripts/create-demo-kubeconfig.sh --compose
TAG=latest docker compose -f deploy/mode-c/compose.release.yaml up

Подключите Codex CLI, добавив следующее в ~/.codex/config.toml:

# ~/.codex/config.toml
[mcp_servers.infra-gate]
url = "http://127.0.0.1:3001/mcp"
oauth_resource = "http://127.0.0.1:3001/mcp"
scopes = ["mcp:tools"]

Затем войдите в систему и запустите:

codex mcp login infra-gate && codex

Полное пошаговое демо — диагностика, план, одобрение, применение и проверка аудита — находится в репозитории проекта.

Общая картина

Экосистема MCP стремительно развивается со стороны возможностей. Разговор о безопасности за ней не успевает. Чего сейчас не хватает в спецификации: стандартизированной семантики для потоков одобрения человеком, руководства по целостности содержимого для предложений мутаций и чёткой модели использования инструментов в контекстах ненадёжных данных.

Команды платформ, оценивающие инструменты на базе ИИ, уже не спрашивают «стоит ли разрешать ИИ трогать наши кластеры?». Этот поезд ушёл — спрос со стороны разработчиков уже движет внедрением. Они спрашивают: «какие средства контроля нам нужны, чтобы мы могли сказать "да"?»

Kubernetes MCP Guard — один конкретный ответ. Если вы упираетесь в ту же стену, откройте issue или discussion на github.com/mirusser/Kubernetes-MCP-Guard.

Примечание об экспериментальном статусе

Дизайн безопасности продуман намеренно, и ключевые функции работают, но проект не готов к продакшну. Известные шероховатости: elicitation требует поддерживающего клиента — клиенты без поддержки MCP elicitation попадают на необработанный путь выполнения; корректный fallback запланирован в roadmap. Хранилище файловое и только для разработки — планы одобрения и журналы аудита пишутся на локальный диск; ApprovalStore — это инжектируемая абстракция, рассчитанная на реализацию с базой данных в продакшне, но такой реализации пока нет. Поддержка платформ узкая — только linux/amd64, CI ориентирован на minikube.

Относитесь к этому как к эталонной реализации паттернов безопасности, а не как к готовому компоненту для установки.

Автор является разработчиком Kubernetes MCP Guard. Проект распространяется с открытым исходным кодом под лицензией Apache-2.0.

Похожее

© 2026 meganuke