Autorisierung gehört in die Plattform, nicht in die App

TL;DR

Viele Unternehmen zentralisieren Identity (Keycloak als IdP), lassen Autorisierung zwischen Diensten aber über Anwendungscode, Gateway-Regeln und Proxy-Konfiguration verstreut. Die Folge: Jede App entscheidet selbst — uneinheitlich und sicherheitskritisch. Besser: Keycloak als zentraler Policy Decision Point, durchgesetzt auf Plattform-Ebene (Istio Ambient + Waypoint) — ohne die Anwendungen zu ändern. Dasselbe Muster gilt für KI-Agents und MCP-Server.

Das Problem: Identity ja, Autorisierung nein

Keycloak für Login und Token-Ausgabe funktioniert in den meisten Organisationen. Autorisierung zwischen Services bleibt oft:

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

Bei Microservices und Agents wird das unkontrollierbar. Genau hier hilft die Trennung:

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

Das Muster: Istio Ambient + Keycloak

Statt Sidecars pro Pod: Istio Ambient mit einem Waypoint pro Namespace. Der Waypoint fängt Layer-7-Traffic ab, fragt Keycloak und lässt nur erlaubte Requests durch. Ein WebAssembly-Plugin übernimmt die Kommunikation mit Keycloak — Open Source, wiederverwendbar.

Ablauf:

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

Zwei Stile:

• UMA (User-Managed Access): Subject ist der User, secret-frei — ideal für Nutzer-Kontexte.
• Client Credentials / Service-Identität: für reine Service-to-Service-Calls.

Betriebs-Realität (ehrlich)

Bezug zu KI-Agents

Dasselbe Muster gilt für Agents und MCP-Server: zentrale Policy entscheidet, welcher Agent welches Tool aufrufen darf — ohne jeden Agent-Code zu ändern. In Kombination mit Identity Chaining und Keyless Identity entsteht ein vollständiges Zero-Trust-Bild: Wer spricht, in wessen Absicht, und was darf er — auf Plattform-Ebene.

Die ehrliche Einordnung:

1. Keycloak als PDP im Live-Pfad braucht HA — Fail-closed ist sicher, aber ein Single Point of Failure.
2. Latency messen, nicht annehmen — 2–3 ms nach Warm-up sind akzeptabel, wenn nachgewiesen.
3. Bypass muss architektonisch unmöglich sein — sonst ist die Kontrolle lückenhaft.
4. UMA vs. Client Credentials — die Wahl hängt vom Subject (User vs. Service) ab.
5. Ohne Observability blind — OpenTelemetry über Keycloak, Plugin und Mesh ist Pflicht.

Häufige Fragen

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.

Müssen Anwendungen geändert werden?

Nein — das ist der Kern. Die Mesh-Ebene setzt durch, die Apps bleiben unverändert.

Was passiert bei Keycloak-Ausfall?

Fail-closed: Zugriff wird verweigert. Deshalb gehört Keycloak in Hochverfügbarkeit.

Fazit

Autorisierung gehört in die Plattform, nicht in jede App und jeden Agenten. Keycloak als PDP plus Istio Ambient als PEP liefert zentrale, fail-closed und observabele Entscheidungen — ohne Code-Änderungen an den Workloads.

Das Muster ergänzt Defense-in-Depth für den Cluster und die VM-Isolation für Agents. Wir beraten, ob Keycloak-as-PDP zu Ihrer Architektur passt, und betreiben die Kette mit HA, Observability und Audit.