Zusammenfassung

  • draft-ietf-wimse-workload-identity-practices-06 beschreibt plattformgestützte, kurzlebige und auf eine Audience begrenzte Credentials als Alternative zu statischen Anwendungs-Secrets.
  • Ein gültiges Credential beweist allein weder die genaue aktive Instanz noch exklusive Schlüsselgewalt, vollständige Ungültigkeit alter Kopien, die konkrete Berechtigung, Ausführung oder Wirkung.

Das Credential ist kein Gesamtzustand

Der Entwurf Workload Identity Practices adressiert eine reale Last. Passwörter, API-Schlüssel und OAuth-Secrets in Anwendungen müssen verteilt und rotiert werden. Werden sie gestohlen, ermöglichen sie bis zur Sperre Identitätsmissbrauch. Plattformen können stattdessen eine Workload beobachten, ein eigenes Credential ausstellen und dessen Tausch gegen ein zielgerechtes Access Token erlauben.

Kubernetes, SPIFFE, Cloud-Metadatendienste, CI/CD und Service Meshes setzen dies verschieden um. Gemeinsam ist die Verringerung langfristiger Secrets, nicht eine universelle Aussagekraft des Tokens.

Der Datatracker-Eintrag führt Revision 06 als aktiven Internet-Draft mit beabsichtigtem Status Informational, beim IESG eingereicht und im Zustand „AD Evaluation::Revised I-D Needed“. Es ist kein RFC, kein Konformitätsnachweis und keine Einsatzbestätigung.

Beleg eins: die Bootstrap-Beobachtung

Vor jeder Signatur entscheidet die Plattform anhand beobachteter Attribute. Das können Host, IP, UID, Prozess, Kernel-Metadaten, cgroup oder Orchestrator-Labels sein. SPIFFE vermeidet ein vorab vorhandenes Secret, indem die Workload API den Aufrufer aus seinem Kontext erkennt. Ein maschinenweiter Selektor bleibt gröber als eine Bindung an Prozess und Instanz.

Ein Bootstrap-Beleg muss Aussteller, beobachtete Attribute, Attestor- und Policy-Version, Zeitpunkt und Entscheidung festhalten. Die spätere Token-Signatur kann nicht zeigen, welche Eingaben nie protokolliert wurden.

Beleg zwei: die lebende Instanz

Die Kubernetes-Dokumentation zu Service Accounts unterscheidet TokenRequest, gebundene Tokens und TokenReview. Ein kubelet fordert nach Pod-Konfiguration Tokens an und liefert sie in Container; Claims können Namespace, Service Account, Pod und Node benennen.

Sie frieren den Cluster nicht ein. Der Pod kann beendet, durch eine Replik ersetzt oder einer geänderten Policy unterstellt werden. Offline-Prüfung bestätigt Signatur und Claims, nicht den aktuellen Bestand des Objekts. Der Entwurf weist darauf hin, dass Löschungs-Invaliderung nur mit TokenReview erkannt wird. Nötig sind konkrete Instanz, Lebenszyklus, Scheduling- und Policy-Epoche sowie Prüfzeit.

Beleg drei: Ausgabe und Zustellung

Korrekte Ausgabe garantiert keinen korrekten Empfänger. Bei Dateien empfiehlt der Entwurf Erneuerung vor Invaliderung, atomaren Austausch und Flush. Lokale APIs über Unix-Socket, Loopback oder Link-Local-Adresse können Credentials liefern und erneuern. Umgebungsvariablen sind statisch und in Diagnosepfaden leicht sichtbar; sie sind bei vorhandener Alternative ungeeignet.

Atomarer rename verhindert eine halb geschriebene Datei, zwingt Prozesse aber nicht zum erneuten Öffnen und löscht keine Speicherkopie. Eine API-Antwort beweist weder die Abwesenheit von SSRF noch privilegiertes Mithören. Der Zustellungsbeleg verbindet Kanal, Instanz, Credential-Hash und Übernahme.

Beleg vier: Besitz ohne Exklusivität

Gestohlene Bearer Tokens können bis zum Ablauf wiederholt werden. Der Entwurf bevorzugt deshalb Proof of Possession. X.509 zeigt Schlüsselkontrolle im Handshake, und ein key-bound JWT verlangt einen zweiten Nachweis. RFC 8705 beschreibt OAuth Access Tokens mit mTLS-Zertifikatsbindung.

Das beweist nur den konkreten Austausch. Es beweist nicht, dass der Schlüssel nie kopiert wurde, nur ein Prozess ihn nutzen kann oder dieser Prozess noch dieselbe Workload ist. Sidecar, Node Agent oder HSM-Schnittstelle können ihn ohne Export verwenden. Exklusive Verwahrung braucht eigene Daten.

Beleg fünf: Audience und konkrete Erlaubnis

Der Entwurf empfiehlt ein Credential pro Ressource oder Identity Provider und eine Audience pro JWT. Ein Token für die Kubernetes API darf nicht zur externen Föderation wiederverwendet werden. So wird der Schadensradius kleiner.

aud sagt jedoch, wer das Token annehmen darf, nicht welche Operation erlaubt ist. RFC 7521 definiert das OAuth Assertion Framework und RFC 7523 JWT Bearer Assertions. Eine akzeptierte Assertion ersetzt nicht die Policy-Prüfung von Verb, Objekt, Parametern und aktuellem Zustand.

Der frühere BTW-Artikel zu Agentic OAuth untersuchte die Autorität über endgültige Modellargumente am ersten Wirkungspunkt. Dieser Artikel untersucht die andere Kette von Bootstrap, Laufzeitbindung, Zustellung, Besitz und Invaliderung.

Beleg sechs: Rotation überall beenden

Kurze Lebensdauer verkürzt das Missbrauchsfenster, sperrt aber nicht sofort. Ein neues File-Credential vor dem alten auszugeben erzeugt bewusst Überlappung. Anwendung, Connection Pool, Proxy oder Retry Queue können den alten Wert halten. Backups, Snapshots und Images können weitere Kopien enthalten; Memory Mounts reduzieren das Risiko, ohne vollständige Löschung zu beweisen.

Der Aussteller sollte jede beendete Instanz separat invalidieren und Statusabfragen anbieten. Die konkrete Mechanik ist im Entwurf nicht festgelegt. „Rotiert“ erfordert Belege über Neuausgabe, Übernahme, Ablehnung oder Ablauf des alten Werts und Drainage bekannter Caches und Instanzen.

Belege sieben und acht: Ausführung und Ergebnis

Die WIMSE-Entwürfe zu Architektur, Credentials, HTTP-Signaturen und mTLS stärken Authentisierungsteile. Keiner beweist die Anwendungswirkung.

Eine Ressource kann Issuer, Zeit, Audience, Typ, Schlüssel und Claims prüfen und die Aktion dennoch verweigern. Sie kann annehmen und vor dem Commit scheitern. Ein geteilter Proxy kann für mehrere Workloads authentisieren. Der ausführende Dienst muss kanonische Anfrage, Autorisierungsentscheidung, Transaktion und Commit quittieren; ein Beobachter des Endzustands quittiert das Ergebnis getrennt.

Heng Lus Trennung von Realitäts- und Symbolebene erklärt den Irrtum: Token und Erfolgsmeldung haben Bedeutung, Realität ist der ausgeführte und beobachtete Zustand. Minimale Spezifikation und lokale Verifikation sowie Running-Code-Primat legen nahe, jeden Beleg nahe am tatsächlich prüfenden System zu halten.

Die belastbare Kette beantwortet acht getrennte Fragen: Was sah die Plattform? Welche Instanz wurde gebunden? Was wurde ausgegeben und geliefert? Welcher Schlüssel wurde bewiesen? Welche Audience und Operation waren erlaubt? Wo endete die Gültigkeit des alten Credentials? Wurde ausgeführt? Trat das Ergebnis ein?