Мультиагентная безопасность Kubernetes: от ThreatEvent до remediation с human-in-the-loop
В Kubernetes вместо одного «security copilot» предлагают сеть специализированных AI-агентов: они совместно расследуют инциденты и координируют ответ. разбор на Dev.to раскрывает Multi-Agent Security Framework — схему agentic AI поверх cloud-native стека с автономным обнаружением, расследованием и remediation под жёстким human-in-the-loop.
Почему команда агентов, а не один ИИ-помощник
Runtime-сканеры, admission, сетевой мониторинг, compliance и CSPM обычно живут отдельно. Итог — alert fatigue, задержки и слабая корреляция. Типовой сценарий: подозрительные команды в контейнере, а дальше вручную собирают ответы про exposure, привилегии, namespaces, lateral movement и нарушения политик.
Вместо монолитного «copilot» — коллаборативное расследование: доменные агенты обмениваются находками, Orchestrator Agent коррелирует сигналы и диспетчеризует ответ, а Shared Intelligence Plane (NATS плюс graph-based context store) остаётся единственным общим ресурсом с доступом через mTLS и workload identities, чтобы агенты не подменяли события друг друга. Каждый агент развёрнут как Kubernetes Deployment со своим ServiceAccount и минимально необходимыми правами.
Domain specialization, collaborative investigation, continuous monitoring, autonomous reasoning, human-in-the-loop governance — пять принципов дизайна, которые автор выносит в начало материала.
Конкретные LLM, промпты или MCP в посте не названы: рамка — agentic / multi-agent оркестрация в security, а не стек coding-IDE.
Три столпа agentic-контура: detection, investigation, remediation
Архитектура строится вокруг трёх автономных фаз — они же вынесены в заголовок поста.
Autonomous Detection. Агенты работают в event-driven циклах и на выходе формируют структурированные ThreatEvent; автор подчёркивает реакцию «в миллисекундах» после сигнала, без опоры только на scheduled scans. В детекции фигурируют eBPF-телеметрия, Falco / Tetragon, проверки NetworkPolicy, admission с Cosign, SBOM против CVE, OPA до schedule.
Autonomous Investigation. Роль Forensic Investigator — directed evidence graph (pods, service accounts, nodes, secrets, external IPs), оценка blast radius, timeline из audit logs, ThreatEvents и deployment history; lookback по умолчанию 30 минут до первого сигнала, поиск patient zero и progression.
Autonomous Remediation. Orchestrator и Remediation Executor скорят инциденты и запускают graduated response с возможностью rollback. Любые действия, затрагивающие control plane, по тексту всегда требуют human approval — без auto-execute на критичной инфраструктуре.
Шесть специализированных агентов
| Агент | Зона ответственности |
|---|---|
| Network Sentinel | eBPF-потоки, cross-namespace, DNS, egress, сканирование портов, нарушения NetworkPolicy |
| Runtime Guardian | Базовые линии workload; отклонения syscall, бинарии, /proc//sys, эскалации; Falco / Tetragon |
| Supply Chain Verifier | Admission: подписи образов (Cosign), SBOM vs CVE, незарегистрированные registry, OPA до schedule |
| RBAC Auditor | Дрифт RBAC vs least-privilege baseline, wildcard ClusterRoleBindings, новые токены в чувствительных namespace |
| Forensic Investigator | Evidence graph, blast radius, timeline, cross-agent correlation |
| Orchestrator + Remediation Executor | Скоринг, диспетчеризация, graduated response |
Топология трёхуровневая: специализированные агенты (domain sensing) → Orchestrator (корреляция и координация) → Shared Intelligence Plane. Это не tutorial по установке одного продукта, а архитектурный разбор ролей и границ ответственности.
Graduated remediation: четыре tier по confidence
Автор задаёт модель порогов confidence — не измеренные метрики вашего кластера, а правила фреймворка:
| Tier | Порог confidence | Действия (по тексту) |
|---|---|---|
| 1 Observe | меньше 0,6 | Лог, контекст, informational alert, без изменений кластера |
| 2 Restrict | 0,6–0,8 | Targeted NetworkPolicy, quarantine metadata на pod, page on-call |
| 3 Isolate | 0,8–0,95 | Evict pod, revoke ServiceAccount tokens, NetworkPolicy по IP range, auto ticket + InvestigationReport |
| 4 Escalate | ≥ 0,95 или impact на control plane | Page security lead, staged actions с one-click approval, без auto-execute |
сигнал → ThreatEvent → скоринг Orchestrator → tier 1–4 → (при tier 4) human approval
Автономный remediation в проде, по мнению автора, безопасен только если дисциплина заложена с самого начала; полный перечень «non-negotiable» production principles в доступном markdown обрезан заголовком без раскрытого списка — в статье его не расширяем.
GKE и пробелы, которые пост не закрывает
В заключении автор отмечает: на GKE часть слоёв можно опереть на managed services Google Cloud, сопоставленные с detection / investigation / remediation; конкретные SKU в тексте не перечислены (на странице — архитектурные PNG).
Чего в материале нет и что нельзя приписывать источнику: публичный GitHub / IaC репозиторий, количественные бенчмарки, названия LLM-оркестраторов, промпты, MCP, Cursor / Copilot как IDE-инструменты (слово copilot в посте — только метафора монолитного помощника). Теги Dev.to: ai, cloud, devops, security; ориентир по объёму — около 5 минут чтения.
Связка с coding-агентами и IDE в тексте поста не раскрыта; сравнивать архитектуру имеет смысл только на уровне паттернов — специализация ролей, общая шина контекста, human-in-the-loop — без домыслов про промпты, MCP или конкретные LLM.
Источники
- Building a Multi-Agent Security Framework for Kubernetes: Autonomous Detection, Investigation, and Remediation — Dev.to (профиль автора
saurabhmi), дата доступа: 2026-06-04 UTC.