In Kubescape 4.0 verschiebt sich der Fokus von reaktiver Sicherheit zu proaktiver Sicherheit. Die wichtigsten Änderungen sind Runtime-Detektion, Überarbeitung des Agentenmodells und die Auslagerung von Sicherheitsdaten aus etcd.
Das Problem zeigt sich im großen Maßstab. Wenn der Cluster wächst, beginnt die Sicherheit, um Ressourcen mit dem Control Plane zu konkurrieren. Die Speicherung von Sicherheitsmetadaten in etcd erhöht die Belastung. Ephemere DaemonSets mit erhöhten Rechten erschweren das Audit. Die Runtime-Detektion erzeugt entweder Rauschen oder kann mit der Last nicht Schritt halten. Zusätzlich kommt eine neue Schicht hinzu – AI-Agenten, die Zugriff auf die Infrastruktur erhalten und die Angriffsfläche erweitern.
In Kubescape 4.0 wurden mehrere zusammenhängende Änderungen vorgenommen. Die Runtime Threat Detection wurde auf GA gebracht und auf CEL (Common Expression Language) umgestellt. Dies bietet eine vorhersehbarere Leistung und direkten Zugriff auf Application Profiles als Baseline. Parallel dazu wurde der Host-Sensor und der Host-Agent entfernt. Stattdessen wurde der Node-Agent verstärkt und eine direkte API-Interaktion mit den Core-Services eingeführt. Dies ist ein Kompromiss: weniger Flexibilität auf Host-Ebene, aber höhere Managebarkeit und Transparenz.
Die Implementierung basiert auf Kubernetes-nativen Ansätzen. Regeln und Bindungen sind als CRD (Custom Resource Definition) gestaltet, was das Betriebsmodell vereinfacht. Alerts können in bestehende Pipelines gesendet werden: AlertManager, SIEM, Syslog, Webhooks. Für die Datenspeicherung wurde Kubescape Storage auf Basis der Aggregated API eingeführt. Dies lagert Application Profiles, SBOM und Vulnerability Manifests aus etcd in eine separate Schicht aus. Dadurch wird der Druck auf den Hauptdatenspeicher verringert und das Verhalten in hochdichten Clustern verbessert. Der Übergang zu einem einheitlichen Node-Agent beseitigt die Notwendigkeit für ephemere Pods mit hohen Rechten, was das Audit vereinfacht.
Ein separater Vektor ist AI. Kubescape fügt die Integration mit KAgent hinzu: AI-Agenten können die Sicherheitslage des Clusters lesen. Gleichzeitig überprüft das System den KAgent selbst. Es wurden 42 kritische Konfigurationspunkte definiert und 15 Rego-Kontrollen hinzugefügt. Dies ist ein Versuch, das zweiseitige Risiko zu schließen: Agent als Analysewerkzeug und Agent als potenzielle Kompromittierungspunkt.
Laut den Ergebnissen wurde die Stabilität der Runtime-Detektion im großen Maßstab erklärt, aber konkrete Metriken wurden nicht angegeben. Architektonisch erscheinen die Änderungen als evolutionär: weniger Komponenten mit erhöhten Rechten, klare Trennung der Speicherung und ein vorhersehbareres Regelmodell. Der Preis ist die Abhängigkeit von Kubernetes API-Erweiterungen und die Notwendigkeit, eine zusätzliche Speicherschicht zu verwalten.