Keycloak für Service-to-Service-Autorisierung: Autorisierung in die Plattform, nicht in die App

TL;DR

• Viele Unternehmen zentralisieren Identity (Keycloak als IdP), aber lassen Autorisierung zwischen Diensten über Anwendungscode, Gateway-Regeln und Proxy-Konfiguration verstreut. Jede Anwendung implementiert Autorisierung selbst — unkontrollierbar, uneinheitlich, sicherheitskritisch.
• Es geht auch anders: Keycloak als zentrale Autorisierungs-Control-Plane (PDP), die Entscheidungen an der Plattform-Ebene durchsetzt — nicht in jeder Anwendung.
• Mit Istio Ambient + Waypoint-Proxy + WebAssembly-Erweiterung bleiben Kubernetes-Workloads unverändert, während eine Mesh-Ebene jede HTTP-Anfrage prüft.
• Das Muster ist fail-closed: Bei Keycloak-Ausfall wird Zugriff verweigert — sicher, aber Keycloak wird zum Single Point of Failure → HA-Architektur ist Pflicht.
• Keine App-Änderungen, kein OPA nötig, kein neues zu lernendes System.

Das Problem: Identity ja, Autorisierung nein

Keycloak für Nutzer-Authentifizierung und Token-Ausgabe funktioniert in den meisten Organisationen. Aber die Autorisierung zwischen Services bleibt oft verstreut:

• in Anwendungscode (jeder Service entscheidet selbst),
• in Gateway-Regeln,
• in proxy-spezifischer Konfiguration.

Das ist unkontrollierbar, uneinheitlich und ein Sicherheitsrisiko — gerade bei vielen Microservices und Agents.

Die Lösung: PDP + PEP auf Plattform-Ebene

Das Muster trennt zwei Rollen:

• PDP (Policy Decision Point): Keycloak trifft alle Entscheidungen — zentral, mit eigener Policy-Engine.
• PEP (Policy Enforcement Point): Die Istio-Ebene setzt die Entscheidung durch — an der Plattform, nicht in der App.

Das Schlüsselwort: Ohne die Anwendungen anzufassen.

Die Architektur

• Istio Ambient Mode statt Sidecars: Kein Proxy pro Pod, sondern ein Waypoint pro Namespace — wirtschaftlicher und einfacher.
• Der Waypoint fängt den Traffic ab, schickt die Anfrage (Header, Body) an Keycloak.
• Keycloak mappt die Anfrage auf Resource/Scope, bewertet gegen Policies und gibt eine Entscheidung zurück.
• Ein WebAssembly-Plugin (Rust) übernimmt die Kommunikation — Open Source, wiederverwendbar.

Der Ablauf

1. User ruft Service A auf (z. B. GET /orders).
2. Service A will Service B erreichen.
3. Der Waypoint greift den Traffic ab, fragt Keycloak: „Darf dieser Aufrufer das?"
4. Keycloak antwortet: Allow oder Deny (mit Scope-Token).
5. Der Waypoint leitet weiter — oder lehnt ab.

In einem Round-Trip (UMA-Ticket-Grant) wird die Entscheidung evaluiert und durchgesetzt.

Zwei Stile der Autorisierung

Die Wahl hängt davon ab, ob das Subject ein User oder ein Service ist. Beide Stile haben ihren Platz — und in modernen Architekturen mit AI-Agents oft beide zugleich.

Die Betriebs-Realität (ehrlich gemessen)

Warum der Bypass-Schutz entscheidend ist

Der wichtigste Punkt für die Sicherheit: Direkter Pod-Zugriff muss architektonisch unmöglich sein. Die Istio-Z-Tunnel-Netzwerk-Policy blockiert jeden Weg am Waypoint vorbei. Nur so ist die Kontrolle lückenlos — sonst umgehen Services die Autorisierung einfach über die direkte Pod-IP.

Warum „Plattform statt App" das richtige Muster ist

Autorisierung in der Plattform bedeutet: eine Kontrollebene, ein Regelwerk, eine Durchsetzung.

• Eine Kontrollebene: Keycloak als zentrale Entscheidungsinstanz statt Policies in hundert Apps.
• Ein Regelwerk: Policies werden einmal gepflegt, nicht in jedem Service dupliziert.
• Eine Durchsetzung: Die Mesh-Ebene setzt überall dieselbe Entscheidung durch.
• Fail-closed: Bei Ausfall wird Zugriff verweigert — nicht geöffnet.
• Observabel: OpenTelemetry über die gesamte Kette (Keycloak, Service, Plugin, Istio), um Entscheidungen, Latency und Fehler zu verstehen.

Das ist genau die Betriebsverantwortung, die Teams abgenommen bekommen: Sie bauen Features, die Plattform stellt sicher, dass nur erlaubter Zugriff passiert.

Die Verbindung zu KI: Agents & MCP unter zentraler Autorisierung

Dasselbe Muster gilt für AI-Agents und MCP-Server: Eine zentrale Policy entscheidet, welcher Agent welches Tool aufrufen darf — ohne jeden Agent-Code zu ändern. In Kombination mit Identity Chaining (RFC 8693/ID-JAG) entsteht ein vollständiges Zero-Trust-Bild:

• Keycloak als PDP entscheidet, welcher Agent welches Tool aufrufen darf
• Waypoint als PEP setzt die Entscheidung durch — ohne App-Änderungen
• Identity Chaining propagiert die Nutzer-Absicht über jeden Hop

Lessons Learned & Risiken (ehrlich)

1. Keycloak als PDP im Live-Pfad braucht HA: Bei Ausfall fail-closed — das ist sicher, aber ein Single Point of Failure. HA-Architektur ist Pflicht.
2. Latency ist messbar, aber beherrschbar: ~2–3 ms nach Warm-up sind im Betrieb akzeptabel — aber gemessen, nicht angenommen.
3. Bypass muss architektonisch unmöglich sein: Direkter Pod-Zugriff wird durch die Istio-Z-Tunnel-Netzwerk-Policy blockiert. Nur so ist die Kontrolle lückenlos.
4. UMA vs. Client Credentials: Beide Stile haben ihren Platz — die Wahl hängt davon ab, ob das Subject ein User oder ein Service ist.
5. Ohne Observability blind: OpenTelemetry über die ganze Kette ist nötig, um Entscheidungen, Latency und Fehler zu verstehen.

Fazit

Autorisierung gehört in die Plattform, nicht in die App. Keycloak als zentrale Autorisierungs-Control-Plane mit Istio Ambient + Waypoint setzt das Muster um — zentral, fail-closed, observabel, ohne App-Änderungen:

1. PDP + PEP auf Plattform-Ebene statt Autorisierung im Anwendungscode.
2. Istio Ambient + Waypoint — ein Waypoint pro Namespace statt Sidecar pro Pod.
3. Fail-closed mit HA — Sicherheit ohne Single Point of Failure.
4. KI-ready — Agents und MCP-Server unter derselben zentralen Policy.

FAQ

Brauchen wir OPA zusätzlich? Nicht zwingend — Keycloak hat eine eigene Policy-Engine. OPA ist eine Alternative, aber ein zusätzliches System. Die Wahl hängt vom Use Case ab.

Muss ich meine Anwendungen ändern? Nein — das ist der Kern des Musters. Die Istio-Plattform-Ebene setzt die Entscheidung durch, die Apps bleiben unverändert.

Was passiert bei Keycloak-Ausfall? Fail-closed: Zugriff wird verweigert. Sicher, aber ein SPOF — deshalb wird Keycloak in HA betrieben.

Ist das nicht zu langsam für Service-to-Service-Calls? In der Praxis sind ~2–3 ms nach Warm-up akzeptabel — gemessen, nicht angenommen. Für die meisten Microservice-Lasten unkritisch.

Verwandte Artikel

• Zero-Trust Architektur für Kubernetes
• Securing Non-Human Identities: Zero-Trust für AI-Agents
• Keyless Identity für AI-Agents auf Kubernetes
• AI-Agent-Sandbox auf Kubernetes: VM-Isolation mit Kata Containers