В Kubescape 4.0 фокус смещается с реактивной безопасности к проактивной. Основные изменения — runtime-детекция, переработка агентной модели и вынос security-данных из etcd.
Проблема проявляется на масштабе. Когда кластер растёт, безопасность начинает конкурировать за ресурсы с самим control plane. Хранение security-метаданных в etcd увеличивает нагрузку. Эфемерные DaemonSet’ы с повышенными правами усложняют аудит. Runtime-детекция либо шумит, либо не успевает за нагрузкой. Отдельно добавляется новый слой — AI-агенты, которые получают доступ к инфраструктуре и расширяют поверхность атаки.
В Kubescape 4.0 сделали несколько связанных изменений. Runtime Threat Detection довели до GA и перевели на CEL (Common Expression Language). Это даёт более предсказуемую производительность и прямой доступ к Application Profiles как baseline’ам. Параллельно убрали host-sensor и host-agent. Вместо этого усилили node-agent и ввели прямое API-взаимодействие с core-сервисами. Это компромисс: меньше гибкости на уровне хоста, но выше управляемость и прозрачность.
Реализация опирается на Kubernetes-native подходы. Правила и привязки оформлены как CRD, что упрощает операционную модель. Alerts можно отправлять в существующие пайплайны: AlertManager, SIEM, Syslog, webhooks. Для хранения данных ввели Kubescape Storage на базе Aggregated API. Это выносит Application Profiles, SBOM и vulnerability manifests из etcd в отдельный слой. Таким образом снижается давление на основной datastore и улучшается поведение в high-density кластерах. Переход на единый node-agent убирает необходимость в эфемерных pod’ах с высокими правами, что упрощает аудит.
Отдельный вектор — AI. Kubescape добавляет интеграцию с KAgent: AI-агенты могут читать security posture кластера. Одновременно система проверяет сам KAgent. Определены 42 критические точки конфигурации и добавлены 15 Rego-контролей. Это попытка закрыть двусторонний риск: агент как инструмент анализа и агент как потенциальная точка компрометации.
По результатам заявлена стабильность runtime-детекции на масштабе, но конкретные метрики не приведены. Архитектурно изменения выглядят как эволюционные: меньше компонентов с повышенными правами, явное разделение хранения, и более предсказуемая модель правил. Цена — зависимость от Kubernetes API-расширений и необходимость управлять дополнительным storage-слоем.