Keyless Identity für AI-Agents: Agents ohne statische Secrets auf Kubernetes

TL;DR

• Das größte Sicherheitsrisiko Ihrer KI ist ein statisches Secret. Ein MCP-Agent bekommt oft einen Client-Secret, der als Umgebungsvariable im Pod liegt — Jahre aktiv, nie rotiert, im Git-Verlauf kopiert. Der Pod ist kurzlebig, das Credential nicht.
• Ein Sicherheits-Audit fand in der Praxis einen 8 Monate alten, nie rotierten Token, der durch Git-History und alle Rollbacks kopiert worden war.
• Die Lösung heißt Keyless Identity: kein Secret, das gestohlen werden kann. Das Ziel in einem Satz: Kein Secret vor dem Pod, kein Secret nach dem Pod, kein Replay während des Pods.
• Das Muster kombiniert erprobte Standards: SPIRE (Workload-Identität), Keycloak (IdP), CIMD (dynamische Client-Registrierung), DPoP (Replay-Schutz) und OPA (Autorisierung).
• Ein gestohlener Access-Token ist wertlos ohne den In-Memory-Key, der nie den Pod verlassen hat.

Warum statische Secrets für Agents scheitern

Das Problem in der Praxis

Ein Krankenhaus betreibt viele kleine Agents auf Kubernetes: Diagnose (liest klinische Daten), Billing (erstellt Rechnungen), Audit (prüft Zugriffe). Jeder Agent braucht strikte Trennung: Diagnose darf lesen, Billing darf nicht auf klinische Daten, Audit darf nichts ändern.

Die heutige Realität:

Der Kern: Der Pod ist temporär, das Credential nicht. Ohne kurzfristige Identität halten auch höhere Kontrollen (HIPAA/GDPR) nicht wirklich.

Das Ziel

• Kein Client-Secret, kein API-Key, kein gemounteter Service-Account-Token, kein Private Key auf Disk.
• Kein Mensch, der Clients von Hand erstellt.
• Zugriffs-Token resistent gegen Replay.
• Autorisierung kommt aus Policy.
• Das Credential stirbt mit dem Pod.

Das Keyless-Muster in 5 Schritten

Das Muster kombiniert erprobte Standards und Projekte: SPIRE (Workload-Identität), Keycloak (IdP), CIMD (dynamische Client-Registrierung), DPoP (Replay-Schutz) und OPA (Autorisierung).

Warum ein gestohlener Token wertlos ist

Ein Angreifer fängt ab: den Access-Token und den DPoP-Proof. Beides ist nutzlos:

• Der Token ist DPoP-gebunden an den Private Key des Pods — der Angreifer hat den Key nicht.
• Der Proof ist Single-Use — ein Replay wird abgelehnt.
• Ein gefälschter Proof mit eigenem Key scheitert an der Key-Bindung des Tokens.

Ein gestohlener Token ist wertlos ohne den Key, der nie den Pod verlassen hat.

Autorisierung: Vertrauensmatrix statt Vertrauen in den Namespace

• Authentifizierung beweist, WER spricht (SPIRE-Identität).
• OPA entscheidet, WAS er darf (Policy pro Tool, pro Trust-Level).
• Der Billing-Agent kann alle krypto-Checks bestehen und trotzdem den Zugriff auf klinische Daten verweigert bekommen. Die Verweigerung ist der Punkt.

Authentifizierung: "Wer spricht?"  → SPIRE (Workload-Identität)
Autorisierung:    "Was darf er?"   → OPA (Policy pro Tool, pro Trust-Level)

Die ehrlichen Grenzen: PC1 → PC2

Der erste Proof-of-Concept hat eine Lücke: Der Pod generiert seinen eigenen Key und „labeled" ihn mit einer Identität — die Identität ist aber nur ein Label, keine kryptografische Bindung. Ein Pod in einem vertrauenswürdigen Namespace kann sich selbst registrieren und Vertrauen nur wegen des Namespace erhalten.

Die Lösung (PC2): Der Agent präsentiert eine von SPIRE signierte SVID als Client-Assertion. Keycloak verifiziert sie gegen das SPIRE-Trust-Bundle (Federated Client Authentication). Vertrauen kommt dann aus verifizierter Identität, nicht aus dem Namespace.

Ein Roboter kann eine URL publizieren, aber keine SPIRE-signierte SVID erzeugen.

Die ehrliche Einordnung: machbar, aber kein Turnkey

Dieses Muster ist heute umsetzbar (Keycloak 26.x, CNCF-Projekte), aber es ist kein Turnkey-Produkt:

• SPIRE-Integration, CIMD-Registrierung, DPoP-Bindung, OPA-Policies und Fail-Closed-Verhalten müssen konfiguriert, getestet und betrieben werden.
• Die echten Grenzen liegen in Kubernetes-RBAC, Network Policies und SPIRE-Selektoren — nicht in einzelnen Tools.
• CIMD und Federated Client Authentication sind teils experimentell — professionelle Validierung nötig.

Fail-Closed ist Pflicht

Wenn SPIRE ausfällt, muss der Agent fail-closed — sonst öffnet der Ausfall eine Lücke. Dazu gehören:

• SVID-Rotation & Revocation — kurzlebige Identitäten, die sich erneuern
• Trust-Bundle-Management — über Umgebungen und Cluster hinweg
• Fail-Closed-Verhalten — kein Zugriff bei Ausfall, statt offener Tür
• Monitoring & Audit — nachweisbar, wer wann was getan hat

Fazit

Keyless Identity dreht die Sicherheitsfrage um: Statt „Wie schützen wir den Schlüssel besser?" die bessere Frage: „Was, wenn es gar keinen Schlüssel mehr zu stehlen gibt?"

1. Statische Secrets sind der größte Risikofaktor — der Pod ist kurzlebig, das Credential nicht.
2. Keyless Muster: SPIRE + Keycloak + CIMD + DPoP + OPA — kein Secret auf Disk, Replay-Schutz, Autorisierung aus Policy.
3. Verifizierte Identität statt Namespace-Vertrauen: Die SPIRE-signierte SVID schließt die Label-Lücke.
4. Das Credential stirbt mit dem Pod — kurzlebig, kryptografisch gebunden, audit-fähig.

FAQ

Was ist „Keyless Identity"? Ein Architekturmuster, bei dem Workloads (Agents) kurzfristige, kryptografisch gebundene Identität zur Laufzeit erhalten — statt statischer Secrets, die gestohlen werden können.

Ist das produktionsreif? Das Muster ist heute umsetzbar, aber nicht Turnkey. Es braucht professionelle Konfiguration und Betrieb — SPIRE-Integration, CIMD, DPoP, OPA-Policies und Fail-Closed-Verhalten.

Was ist der größte Vorteil? Ein gestohlener Access-Token ist nutzlos ohne den In-Memory-Key des Pods. Kein Secret vor dem Pod, kein Secret nach dem Pod, kein Replay während des Pods.

Reicht nicht ein gut verwaltetes Secrets-Management? Es reduziert das Risiko, aber das Secret bleibt stehlbar. Keyless Identity entfernt die Angriffsfläche strukturell — es gibt nichts mehr zu stehlen.

Verwandte Artikel

• Securing Non-Human Identities: Zero-Trust für AI-Agents
• Keycloak für Service-to-Service-Autorisierung in Kubernetes
• AI-Agent-Sandbox auf Kubernetes: VM-Isolation mit Kata Containers
• Agentic AI auf Kubernetes in der Praxis
• Llama Stack: Enterprise-KI-Plattform
• Zero-Trust Architektur für Kubernetes