Zusammenfassung

  • Revision 07 verbietet mehr als eine Audience pro JWT, außer mehrere Nachweise können nicht beschafft oder die Audience kann nicht beeinflusst werden; Revision 06 formulierte die einzelne Audience nur als SHOULD.
  • Das Risiko ist eine Identitätsübernahme zwischen Empfängern: Jede Stelle mit demselben Bearer-Token kann es einer anderen akzeptierenden Stelle vorlegen.
  • Ein Fähigkeitsausnahme-Beleg sollte Grund, Empfängergraph, Lebensdauer und Reichweite, Prüfungen, Kompensationen, Wiedervorlage und Ausstiegsbedingung festhalten.

Ein Pod verwendet sein projiziertes Service-Account-Token beim Kubernetes-API-Server und danach noch einmal zur Föderation mit einem externen Identitätsanbieter. Beide Ziele sind legitim. Doch beide halten nun dasselbe Bearer-Token. Lässt dessen aud beide Verwendungen zu, kann der externe Anbieter es beim API-Server vorlegen und als Workload auftreten.

Dafür braucht es weder einen Mitschnitt auf dem Transportweg noch ein kompromittiertes Protokoll oder einen gebrochenen Aussteller. Der legitime Empfänger selbst wird zum möglichen Impersonator, weil der Nachweis die Grenze zum zweiten Empfänger nicht bewahrt. Jede lokale Prüfung kann richtig sein, obwohl die Systemgrenze falsch gezogen ist.

Das ist die entscheidende Änderung in draft-ietf-wimse-workload-identity-practices-07, hochgeladen am 22. September 2026. Das Dokument ist weiterhin ein aktiver Internet-Draft mit vorgesehenem Status Informational. Datatracker zeigt AD Evaluation::AD Followup und Charles Eckel als Action Holder. Das ist weder eine Genehmigung noch ein RFC, ein Bereitstellungsnachweis oder ein Compliance-Urteil über eine benannte Plattform.

Aus SHOULD wird eine begründungspflichtige Grenze

Revision 06 wies bereits in die richtige Richtung. Nachweise sollten möglichst eng begrenzt sein; sofern die Plattform mehrere ausstellen kann, sollte eine Workload für jede Ressource oder jeden Identitätsanbieter einen eigenen erhalten. Für JWTs hieß es, sie sollten nur eine Audience tragen.

Revision 07 macht daraus die Regel. Nachweise MUST so eng wie möglich beschränkt sein. Ein Plattformnachweis MUST auf die betreffende Ressource zielen. Ein Föderationsnachweis MUST den Identitätsanbieter als einzige Audience tragen. Abgesehen von der Fähigkeitsausnahme darf ein JWT nicht mehr als eine Audience enthalten.

Das ist mehr als eine redaktionelle Großschreibung. SHOULD erlaubt eine begründete Abweichung; MUST erklärt Trennung zum Normalfall und verschiebt die Begründung zur Ausnahme. Der Entwurf nennt zudem den Mechanismus: Jede im selben aud genannte relying party kann das Token einer anderen vorlegen und unbeabsichtigten Zugriff erlangen.

Audience ist damit kein beiläufiges Routingmerkmal. Sie bezeichnet die Orte, an denen der Nachweis sprechen darf. Jeder weitere Empfänger ist zugleich ein weiterer Inhaber mit Replay-Möglichkeit gegenüber den übrigen Empfängern.

Drei Plattformmuster, derselbe Empfängergraph

Kubernetes kann mehrere projizierte Tokens mit eigener Audience und Laufzeit ausstellen. Revision 07 trennt API-Server, interne Ressource und externen Identitätsanbieter. Die drei Wege müssen unterschiedliche Tokens mit unterschiedlichen Audiences verwenden.

Eine korrekte aud-Prüfung an jedem Ort repariert keinen gemeinsam genutzten Nachweis. Der externe Anbieter kann Aussteller, Signatur, Ablauf und Audience korrekt prüfen und dennoch ein Token halten, das auch der API-Server akzeptiert. Alle lokalen Kontrollen können grün sein, während die übergreifende Trennung scheitert.

Bei SPIFFE müssen JWT-SVID für interne Ressourcen und JWT-SVID für externe Föderation ebenfalls getrennt sein. Beim Cloud-Muster werden SHOULD und SHOULD NOT aus Revision 06 für internen Zugriff und externen STS zu MUST und MUST NOT. Entscheidend ist nicht das Produkt, sondern die Menge der Empfänger desselben Nachweises.

Die Ausnahme benennt eine Lücke

Manche Plattformen stellen nur einen Nachweis je Workload aus; andere lassen die Workload die Audience nicht beeinflussen. Revision 07 erlaubt deshalb eine Ausnahme, wenn mehrere Nachweise nicht erhältlich sind oder die Audience nicht steuerbar ist.

Das ist kein Komfortpfad. Ein solcher Betrieb kann sich zur Schadensbegrenzung nicht auf Audience-Scoping verlassen. Er muss die kürzeste mögliche Laufzeit wählen, den Kreis zugreifender Komponenten begrenzen und jeden Empfänger so behandeln, als könne er die Workload bei jedem anderen Empfänger impersonieren.

Die Last wandert von kryptografischer Trennung zu Zeit, Komponentenrechten, Netzpfaden, Validierung und Erkennung. Das sind Kompensationen, keine Gleichwertigkeit. Ähnlich verschärft Revision 07 die Lage ohne Proof of Possession: kürzere Laufzeiten, engere Audiences und zusätzliche Netzmaßnahmen werden Pflicht. Ein kurzlebiges Bearer-Token bleibt für jeden nutzbar, der es besitzt.

Der Fähigkeitsausnahme-Beleg

Ein belastbarer Beleg sollte mindestens enthalten:

Feld Nachweis
Ausstellerfähigkeit Plattform, Aussteller, exakte Version, Mehrfachausstellung
Audience-Steuerung Kann die Workload aud anfordern oder beeinflussen, belegt durch API oder Konfiguration
Zweck Plattform-API, interne Ressource, Föderation oder externe Ressource
Nachweisidentität Nicht geheime Einweg-Fingerabdruck- oder Generationskennung, nie der Tokenwert
Empfängergraph Alle Akzeptoren und Präsentationspfade untereinander
Lebensdauer Angeforderte und ausgestellte TTL, Erneuerung, Widerruf oder Ungültigkeit
Reichweite Komponenten, Mounts, Sidecars, Proxys, Logs und Ausgänge mit Zugriff
Validierung Aussteller, Audience, Typ, PoP und Netzbedingungen je Empfänger
Ausnahmegrund Fehlende Fähigkeit und Grund der Untrennbarkeit
Kompensation Kürzere Laufzeit, Zugriffsbeschränkung, Netz, Monitoring und Alarmierung
Überprüfung Verantwortlicher, Zeitpunkt, nächste Prüfung, Korrekturtrigger und Ausstieg

Der Fingerabdruck muss nicht geheim und nicht umkehrbar sein. Der Beleg darf nie zum Anlass werden, das Bearer-Token in ein Ticket zu kopieren. Er verbindet eine Risikoentscheidung mit genau der Generation, den Empfängern und Kontrollen, für die sie getroffen wurde.

Er trennt auch „nicht möglich“ von „nicht umgesetzt“. Kann der Aussteller getrennte Nachweise liefern, die Integration verwendet aber aus Bequemlichkeit einen, greift die Ausnahme nicht. Fügt eine spätere Version Audience-Steuerung hinzu, ist die Ausstiegsbedingung erreicht. Ohne Prüftermin wird eine vorläufige Ausnahme unbemerkt zur Architektur.

Der frühere BTW-Beitrag A Workload Credential Is Not the Workload ordnete acht Nachweise zwischen Bootstrap und Ergebnis. Dieser Beitrag bleibt enger: Bei welchen Empfängern kann genau dieses Bearer-Token für die Workload sprechen, und wohin können diese Empfänger es weitertragen?

Quellen und Grenzen

Primärquellen sind der Datatracker-Eintrag zu Revision 07, die Dokumenthistorie, der unveränderliche Text von Revision 07 und der Text von Revision 06. Die Trennung von Koordinationsartefakt und Betriebswirklichkeit folgt Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

Die Quellen belegen Dokumentstatus, Normsprache und Risikomechanismus. Sie belegen keinen realen Vorfall, keine vollständige Implementierungsübersicht und keinen Verstoß eines benannten Betreibers. Der Beleg ist ein redaktioneller Vorschlag von Daniel Kade, keine Vorgabe des WIMSE-Entwurfs.