Erweiterung der Kubernetes-Policy-Durchsetzung um Laufzeitsicherheit für KI-Workloads

GPU-Teams stehen vor einem schlechten Kompromiss: ein Control Plane pro Team oder schwache Isolation in einem gemeinsamen Cluster. Dieses reproduzierbare Labor kombiniert Kamaji (Control Planes als Pods) und HAMi (fraktionierte GPUs) auf einer einzigen Maschine ohne GPU, unter Verwendung von HAMis Mock-Device-Plugin.

Nirmata hat Kyverno entwickelt und 2020 an die CNCF gespendet. Kyverno ist inzwischen ein graduiertes CNCF-Projekt und wird weithin zur Durchsetzung und Automatisierung von Konfigurationssicherheit auf Kubernetes eingesetzt. Doch Admission Control beantwortet nur eine Frage: Sieht dieses Spec richtig aus? Sie kann nicht die Frage beantworten, die zählt, sobald der Pod läuft: Macht dieser Workload das, was sein Spec vorgibt?

Bei autonomen KI-Agenten und nicht-deterministischen LLM-gestützten Anwendungen ist genau diese Lücke der Ort, an dem die interessanten Vorfälle passieren.

Die Laufzeitlücke, die Admission Control nie schließen sollte

Die Ausfallszenarien sind jedem bekannt, der Agenten betreibt:

• Ein Container mit einem harmlos wirkenden Image zieht nach dem Start eine Second-Stage-Payload nach.
• Ein Sidecar mit Netzwerkzugriff, den niemand eng genug begrenzt hat, beginnt, mit einem Ziel zu kommunizieren, das niemand genehmigt hat.
• Ein Prozess wird ausgeführt, den keine Konfigurationspolicy vorhergesehen hat – weil die Policy nur das deklarierte Verhalten des Containers beschrieben hat, nicht sein Laufzeitverhalten.

Ein Ansatz ist die Kernel-Level-Laufzeitdurchsetzung: Sicherheitsentscheidungen werden während der Ausführung von Workloads angewendet. Nirmata Runtime for Kyverno ist eine Open-Source-Implementierung davon, die eBPF und Linux Security Modules (LSM) nutzt, um die Policy-Durchsetzung über die Admission Control hinaus zu erweitern.

Unter dem Workload, nicht daneben

Das Designprinzip ist einfach: Jede Kontrolle, die neben einem Workload läuft – ein Sidecar, ein Agent, ein Userspace-Proxy – kann von der Kompromittierung des Workloads selbst gesehen, gestoppt oder umgangen werden. Eine Kontrolle, die darunter im Kernel läuft und an derselben Instruktion wie der Syscall, den sie überwacht, durchsetzt, befindet sich nicht in dieser Position. Der Workload hat kein Mitspracherecht.

Konkret bindet Nirmata Runtime BPF-LSM-Programme direkt an bprm_check_security und file_open sowie cgroup-bezogene eBPF-Programme an den Egress-Pfad, pro Pod. Fünf Verhaltensweisen werden im Kernel synchron mit der Operation, die sie überwachen, entschieden:

• exec – Prozessausführung über den aufgelösten Kernel-Pfad verweigern
• open – Dateizugriff über den aufgelösten Kernel-Pfad verweigern
• network – Egress nach Ziel verweigern
• protocol – nach dem tatsächlich gesprochenen Anwendungsprotokoll verweigern, unabhängig vom Zielport (eine Reverse Shell, die sich als HTTPS auf 443 tarnt, bekommt keinen Pass, nur weil der Port richtig aussieht)
• dns – beobachten und berichten, ohne zu blockieren – DNS-Blockierung hat schlimmere Ausfallmodi als der Verkehr, den sie stoppen würde

Eine blockierte exec-Ausführung gibt -EPERM zurück, bevor der Prozess läuft. Eine blockierte Verbindung wird nie abgeschlossen. Es gibt kein Fenster zwischen „Entscheidung" und „Durchsetzung", das ein kompromittierter Workload ausnutzen könnte.

Wiederverwendung von Kubernetes-Policy-Konzepten

Wenn Sie bereits Kyverno-Policies für Admission schreiben, kennen Sie die Policy-Sprache: CEL. RuntimePolicy zielt auf Workloads genauso ab – podSelector/namespaceSelector – und drückt Allow/Deny-Logik pro Verhalten aus, einschließlich Ausdrücken, die Live-Werte aus einer ConfigMap oder einer HTTP-Quelle in einem Aktualisierungsintervall ziehen. Admission und Laufzeit werden zu einer durchgängigen Policy-Geschichte statt zweier Syntaxen, die mit Stammeswissen darüber, welche zuerst geprüft wird, zusammengeklebt sind.

Jede Policy wird standardmäßig im Monitor-Modus ausgeliefert. Sie beobachten, was sie verweigern würde – einschließlich eines WouldDeny-Kontrafaktualsignals – bevor Sie sie auf Enforce umstellen. Nichts geht stillschweigend in den Blockierungsmodus. Es verwendet auch dieselben Reporting-APIs (OpenReports) und wird feingranulare Ausnahmen ähnlich wie Kyverno hinzufügen.

Warum das für KI-Agenten wichtig ist

Ein Coding-Agent, ein MCP-Server, ein autonomer Pipeline-Schritt – das sind auch Pods. Aber Agenten werfen eine Frage auf, die Admission Control nie beantworten sollte: Das Verhalten eines Agenten ist zum Zeitpunkt der Bereitstellung nicht vollständig bekannt, weil ein Teil dessen, was er tut, von einem Modell zur Laufzeit generiert wird. Sie können das Image überprüfen; Sie können keine Entscheidung überprüfen, die der Agent noch nicht getroffen hat.

Für KI-Workloads mit dynamisch bestimmtem Verhalten fügt die Kernel-Level-Durchsetzung eine Kontrollebene hinzu, die unabhängig von Anwendungsebenen-Sicherheitsvorkehrungen arbeitet – und Netzwerk-Policies, Admission Controls und Anwendungsebenen-Guardrails ergänzt. Wenn die Laufzeit eines Agenten kompromittiert ist (Prompt Injection, Supply-Chain-Abhängigkeit, ein Tool, das außerhalb seiner Grenzen handelt), gelten die Kernel-Kontrollen weiterhin für die von Ihnen deklarierte Policy, egal was das Modell als Nächstes entscheidet.

Fazit

Das Muster ist überzeugend: Policy einmal ausgedrückt, in einer Sprache, die Betreiber bereits kennen, durchgesetzt an einem Ort, an dem ein kompromittierter Workload sie nicht neutralisieren kann. Admission Control bleibt für das, was sie gut kann; die In-Kernel-Laufzeitdurchsetzung deckt das Verhalten ab, das Admission nie sieht. Genau diese Art von Defense-in-Depth brauchen KI-Workloads.