Sicherheit von AI-Agenten in Kubernetes erfordert eine Überprüfung grundlegender Annahmen. Das dynamische Verhalten bricht die gewohnten Modelle von RBAC, Netzwerkrichtlinien und Ressourcengrenzen.
Das Problem zeigt sich nicht sofort — bis der autonome Agent beginnt, sich wie ein System ohne feste Grenzen zu verhalten. In dem klassischen Modell von Kubernetes wird ein vorhersehbarer Satz von Abhängigkeiten, ein stabiler Lastprofil und ein begrenzter Zugang zu externen APIs angenommen. Dies hat der AI-Agent nicht. Er bestimmt selbst, welche Datenquellen abgefragt werden, welche Hypothesen überprüft werden und welche Schritte unternommen werden. Dies führt zu verschwommenen Vertrauensgrenzen, der Unmöglichkeit, korrekte Netzwerkrichtlinien festzulegen, und dem Fehlen einer Basislinie für die Anomalieerkennung. Zusätzlich steigt das Risiko: Ein Container kann gleichzeitig Zugriff auf Logs, Metriken, Netzwerküberwachung und externe APIs haben.
Die Lösung erwies sich als pragmatisch: Die Isolationseinheit wurde von dem Dienst auf die Ebene einer einzelnen Untersuchung verschoben. Statt eines long-running Deployments — ein Kubernetes Job für eine Aufgabe des Agenten. Dies ist ein Kompromiss zwischen Startgeschwindigkeit und Kontrolle. Ja, es entsteht ein gewisser Overhead beim Start (einige Sekunden), aber dieser ist im Vergleich zur Ausführungszeit, die Minuten in Anspruch nehmen kann, gering. Dafür entsteht eine strikte Isolation in Bezug auf Ressourcen, Ausfälle und Zustand. Parallel wird Vault zur Verwaltung von Geheimnissen mit kurzer Lebensdauer verwendet, um den Blast Radius bei einer Kompromittierung zu begrenzen.
Die Implementierung hängt von den Details der Orchestrierung und des Zugriffsmanagements ab. Jeder Job erhält eigene CPU- und Speicherkapazitätsgrenzen, was den Wettbewerb zwischen „schweren“ und „leichten“ Untersuchungen beseitigt. Die Fehlerisolierung funktioniert auf der Ebene von Kubernetes: Der Ausfall eines Jobs hat keinen Einfluss auf die anderen. Der saubere Zustand des Containers schließt Kontextlecks und die Ansammlung von Artefakten aus. Logs und Metriken sind an einen bestimmten Job gebunden, was die Nachverfolgbarkeit und Prüfung vereinfacht.
Geheimnisse werden zu einer separaten architektonischen Aufgabe. Der Agent benötigt Schlüssel für mehrere Domänen: Logging, Metriken, Netzwerk, LLM API. Diese statisch zu speichern, ist riskant. Es wird Vault verwendet: Authentifizierung über Service-Account, Ausgabe temporärer Anmeldeinformationen für die Dauer der Ausführung des Jobs, automatische Widerrufung nach Abschluss. Dies verringert das Angriffsfenster und beseitigt die Notwendigkeit einer Rotation über das Deployment. Dabei wurde ein Kompromiss gewählt: eine einheitliche Identität für den Agenten mit domänenspezifischen Richtlinien, anstelle einer einzigartigen Identität für jeden Job. Dies vereinfacht die Operationen, verringert jedoch die Genauigkeit der Attribution.
Eine separate Schicht — das Vertrauensmodell. Der Übergang zur Autonomie ist in Phasen unterteilt: von der read-only Analyse bis zur vollständigen automatischen Behebung. Der entscheidende Punkt ist, dass Entscheidungen nicht nach Fahrplan, sondern nach betrieblichen Signalen getroffen werden. Die Vertrauensmetrik ist nicht die Genauigkeit, sondern das Verhalten der Betreiber: wie oft sie die Schlussfolgerungen des Agenten ändern. Dieser Ansatz verringert das Risiko einer vorzeitigen Automatisierung und ermöglicht eine kontrollierte Evolution.
Die Ergebnisse sind qualitativ. Das System wird vorhersehbarer unter Bedingungen unvorhersehbarer Arbeitslasten. Die Isolation durch Jobs beseitigt eine Klasse von Problemen mit Ressourcenwettbewerb und hängenden Prozessen. Vault verringert den Blast Radius und vereinfacht die Rotation von Geheimnissen. Es bleiben jedoch Trade-offs: die Komplexität der Orchestrierung, das Wachstum der Objekte im Cluster und die Notwendigkeit einer reiferen Observability. Effizienzmetriken werden nicht angegeben, aber die architektonischen Effekte entsprechen den Erwartungen für solche Muster.
Die Hauptschlussfolgerung: AI-Agenten sind eine neue Klasse von Arbeitslasten. Sie erfordern eine Überprüfung der grundlegenden Prinzipien der Kubernetes-Sicherheit und -Verwaltung. Der Versuch, sie in das Modell der Mikrodienste zu integrieren, führt zu versteckten Ausfällen, die sich bereits in der Produktion zeigen.