Консоль безопасности Kubernetes на базе MCP: как связать сигналы Falco, Trivy и Kyverno в единый триаж для ИИ-агентов

Консоль безопасности Kubernetes на базе MCP: как связать сигналы Falco, Trivy и Kyverno в единый триаж для ИИ-агентов

В эксплуатации Kubernetes отдельный сигнал безопасности редко отражает полную картину происходящего. Оповещение времени исполнения «В контейнере запущен командный интерпретатор shell» может означать как активную компрометацию инфраструктуры, так и ручную отладочную сессию инженера или штатный запуск CI-задачи. Критическая уязвимость в базовом образе может требовать немедленного реагирования, а может затрагивать библиотеку, код которой приложение никогда не вызывает.

Главная проблема современной безопасности контейнеров заключается не в слабой чувствительности сканеров, а в разобщенности их сигналов. Falco отслеживает поведение ядра, Trivy сканирует уязвимости в образах, Kubescape оценивает соответствие стандартам конфигурации (posture), а Kyverno контролирует политики допуска манифестов. Однако эти инструменты не образуют единой плоскости расследования.

В инженерной серии проекта Building an OSS Kubernetes Security Console with MCP предложен архитектурный фреймворк консоли безопасности, построенной вокруг открытого протокола Model Context Protocol (MCP). Вместо развертывания тяжеловесных SIEM-систем или передачи неструктурированных дампов YAML языковым моделям, решение использует нативные пользовательские ресурсы Kubernetes (CRD) как разделяемый слой данных и типизированный MCP-сервер как слой контролируемых запросов для ИИ-агентов.

Архитектурный фундамент: почему нативные CRD стали разделяемым слоем

Если каждый инструмент безопасности сохраняет результаты в собственном проприетарном формате, оператору приходится вручную сопоставлять разнородные JSON-логи, связывать идентификаторы подов с владельцами и проверять версии образов.

Использование пользовательских ресурсов Kubernetes (Custom Resource Definitions, CRD) решает проблему стандартизации данных:

1. Единая плоскость API. Доступ к отчетам безопасности осуществляется через стандартный Kubernetes API, встроенные механизмы авторизации (RBAC), пространства имён (namespaces) и селекторы меток (labels).
2. Нативная привязка к сущностям. Объекты Kubernetes уже содержат ссылки на владельцев (ownerReferences): репликасеты, деплойменты, контейнеры и дайджесты образов.
3. Совместимость с CLI. Инженер или агент может запросить сводное состояние кластера стандартной командой kubectl get vulnerabilityreports,policyreports -A.

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

В отличие от отчетов сканеров, события Falco представляют собой непрерывный поток телеметрии ядра Linux на базе eBPF. Запись каждого алерта в CRD перегрузила бы хранилище etcd. Поэтому Falcosidekick перенаправляет поток алертов в легковесный HTTP-синк (а в продакшене — в Loki, Elasticsearch или Splunk), к которому MCP-сервер обращается наряду с Kubernetes API.

Слой запросов: типизированный MCP-сервер вместо неструктурированных промптов

Передача «сырых» дампов конфигурации и логов в контекст языковой модели приводит к галлюцинациям, высокому расходу токенов и потере важных связей.

Протокол Model Context Protocol (MCP) стандартизирует взаимодействие между ИИ-ассистентами и внешними инструментами. Архитектура консоли предоставляет агенту набор узкоспециализированных функций:

• list_runtime_events(namespace, hours) — выборка недавних поведенческих алертов из Event Sink с фильтрацией по времени.
• list_vuln_reports(namespace, severity) — запрос отчетов Trivy Operator по критичности уязвимостей.
• list_policy_violations(namespace, result) — получение списка нарушений политик Kyverno (в режимах Audit и Enforce).
• list_compliance_reports(framework) — проверка соответствия стандартам CIS Benchmarks и рекомендациям NSA-CISA через Kubescape.

Агент оперирует структурированными данными и получает конкретные факты: дайджест образа, имя пода, наличие исправленной версии пакета и статус политики.

Сценарий корреляции: расследование инцидента через скилл /triage-threat

Преимущество архитектуры раскрывается в процессе сквозного триажа инцидентов. Рассмотрим сценарий работы специализированного агентного сценария (скилла) /triage-threat:

1. Получение первичного алерта

В системе фиксируется событие Falco:

Unexpected shell spawned in container
namespace=demo
pod=checkout-api-7c9dfb8f6d-k2p9s
container=checkout-api
command=/bin/sh

2. Определение контекста рабочей нагрузки

Агент запрашивает метаданные пода, определяя контролирующий Deployment (checkout-api) и точный хэш запущенного контейнерного образа.

3. Сопоставление с отчетами сканеров

• Через list_vuln_reports агент проверяет отчет Trivy: оказывается, образ содержит две критические уязвимости с доступными патчами.
• Через list_policy_violations проверяется статус Kyverno: выясняется, что для пода зафиксировано нарушение политики безопасности (разрешено повышение привилегий allowPrivilegeEscalation: true в режиме аудита).
• Через list_compliance_reports запрашиваются данные Kubescape: сервис использует ServiceAccount с избыточными правами.

4. Синтез вывода для инженера

Вместо изолированного уведомления о запуске shell оператор получает структурированное заключение:

Инцидент: Запуск shell в поде checkout-api подтвержден как высокорисковый.
Контекст угроз: Образ содержит критические уязвимости с готовым фиксом; конфигурация допускает эскалацию привилегий; сервисный аккаунт имеет избыточный доступ к API.
Рекомендации: Изолировать сетевой доступ пода сетевой политикой, обновить базовый образ до версии с устраненными CVE и перевести политику Kyverno в режим принудительной блокировки (Enforce).

Разграничение прав и безопасность MCP-сервера

Интеграция ИИ-агентов в инфраструктуру Kubernetes требует строгого соблюдения принципа наименьших привилегий (Least Privilege):

1. Сервисный аккаунт MCP-сервера. Учетная запись должна обладать правами исключительно на чтение (get, list, watch) строго определенных типов ресурсов: vulnerabilityreports, policyreports, clustercompliancereports и базовых метаданных подов. Назначение роли cluster-admin недопустимо.
2. Разделение расследования и реагирования. В рамках архитектуры агент выполняет только аналитический триаж (read-only). Автоматическое изменение манифестов, удаление подов или модификация политик исключены: любые корректирующие действия требуют проверки и подтверждения дежурным инженером.

Границы применимости и возможности первой версии

При внедрении консоли важно четко понимать границы возможностей фреймворка:

Что решает архитектура:

• Создает прозрачную, воспроизводимую процедуру триажа алертов.
• Исключает эффект «черного ящика»: все выводы агента опираются на верифицируемые объекты Kubernetes API.
• Устраняет рутинные операции по ручному сопоставлению логов и отчетов сканеров.

Чем решение не является:

• Не заменяет полноценный SIEM. Архитектура не предназначена для долговременного хранения терабайтов аудиторных логов.
• Не выполняет автономное устранение угроз. Решение ориентировано на поддержку принятия решений оператором.
• Не доказывает факт эксплуатации. Наличие уязвимости и запуск shell создают высокую вероятность угрозы, но требуют окончательной валидации специалистом по безопасности.

Фреймворк консоли безопасности на базе нативных CRD и протокола MCP демонстрирует практичный подход к автоматизации DevSecOps: использование открытых инструментов (Falco, Trivy Operator, Kyverno, Kubescape) в сочетании с типизированными интерфейсами превращает разрозненные алерты в структурированный контекст расследования.