Résumé

  • La révision 07 interdit à un JWT de porter plus d’une audience, sauf si plusieurs justificatifs ne peuvent pas être obtenus ou si la charge de travail ne peut pas agir sur l’audience ; la révision 06 ne formulait qu’une recommandation.
  • Le risque est une usurpation entre récepteurs : chaque partie qui reçoit le même jeton porteur peut le présenter à une autre partie qui l’accepte.
  • Un reçu d’exception de capacité doit conserver la cause de l’exception, le graphe complet des récepteurs, la durée et la portée du jeton, les validations, les compensations, la date de réexamen et la condition de sortie.

Un Pod peut sembler suivre deux parcours parfaitement ordinaires. Il utilise un jeton de compte de service projeté pour joindre le serveur d’API Kubernetes, puis réemploie ce jeton auprès d’un fournisseur d’identité externe afin d’obtenir un autre titre d’accès. Les deux destinataires sont légitimes. Pourtant, si le même jeton est recevable aux deux endroits, le fournisseur d’identité peut le présenter au serveur d’API et parler au nom de la charge de travail.

Cette possibilité n’exige ni vol en transit, ni journal compromis, ni rupture cryptographique chez l’émetteur. Elle naît du fait qu’un récepteur autorisé devient détenteur d’un bearer token réutilisable. La validation peut réussir partout, alors que la frontière entre les systèmes a déjà disparu.

C’est le point décisif de draft-ietf-wimse-workload-identity-practices-07, déposé le 22 septembre 2026. Le texte demeure un Internet-Draft actif destiné à la catégorie Informational. Datatracker l’indique en AD Evaluation::AD Followup, avec Charles Eckel comme responsable de l’action. Ce statut ne signifie ni approbation, ni publication d’un RFC, ni déploiement, ni non-conformité d’une plateforme nommée.

Le passage de SHOULD à MUST change qui doit s’expliquer

La version 06 indiquait déjà la bonne direction : réduire autant que possible la portée d’un justificatif et, lorsque la plateforme peut en produire plusieurs, utiliser un justificatif distinct par ressource ou fournisseur d’identité. Sa section sur l’audience disait qu’un JWT ne devrait porter qu’une seule audience.

La version 07 en fait la règle. Les justificatifs MUST être limités aussi étroitement que possible. Celui qui sert une ressource de plateforme MUST être destiné à cette ressource. Celui qui sert à la fédération MUST avoir le fournisseur d’identité pour seule audience. Sauf exception de capacité, un JWT MUST NOT contenir plus d’une audience.

Le changement n’est pas décoratif. SHOULD laisse place à un choix raisonné ; MUST fait de la séparation la situation par défaut et oblige l’exception à rendre son motif visible. Le texte expose en outre le mécanisme : toute relying party citée dans le même champ aud peut présenter le jeton à une autre et obtenir un accès non prévu.

L’audience n’est donc pas une simple étiquette de routage. Elle décrit les endroits où le justificatif peut parler. Ajouter un récepteur, c’est aussi ajouter un détenteur capable de rejouer le jeton vers les autres récepteurs.

Trois familles de plateforme, une même géométrie

Kubernetes sait créer plusieurs jetons projetés, chacun avec son audience et sa durée. La révision 07 distingue le serveur d’API, une ressource interne et un fournisseur d’identité externe : les trois usages doivent recevoir des jetons différents et des audiences différentes.

Le contrôle local de aud ne suffit pas si deux récepteurs acceptent le même bearer token. Un fournisseur d’identité peut vérifier correctement l’émetteur, la signature, l’expiration et l’audience, tout en conservant un titre également recevable par le serveur d’API. Des validations locales exactes peuvent donc composer un système globalement mal isolé.

L’exemple SPIFFE suit la même logique : le JWT-SVID destiné à une ressource interne et celui destiné à la fédération doivent être distincts. Dans le scénario de fournisseur cloud, la version 06 disait qu’une charge de travail devrait obtenir des justificatifs séparés et ne devrait pas réutiliser celui de la plateforme auprès d’un STS externe. La version 07 emploie MUST et MUST NOT. Le nom de la plateforme change ; le graphe des récepteurs reste l’objet de sécurité.

L’exception décrit une lacune, pas une équivalence

Le projet reconnaît que certaines plateformes n’émettent qu’un justificatif par charge de travail ou ne laissent pas celle-ci influencer l’audience. L’exigence d’audience unique cède alors si plusieurs justificatifs ne peuvent pas être obtenus ou si l’audience ne peut pas être contrôlée.

Cette exception ne légalise pas la commodité. Le texte dit qu’un tel déploiement ne peut compter sur l’audience pour contenir une compromission. Il doit réduire la durée au minimum permis, limiter les composants qui atteignent le justificatif et considérer tout récepteur comme capable d’usurper la charge de travail auprès de tous les autres.

Le niveau d’isolement n’est pas équivalent. La défense passe de la séparation cryptographique à la durée, à l’accès des composants, aux chemins réseau, aux contrôles de validation et à la détection. Ces compensations peuvent être justifiées ; elles doivent rester identifiées comme le prix d’une capacité absente.

La révision 07 suit la même discipline pour la preuve de possession. Lorsque plateforme et relying party ne la prennent pas en charge, des durées plus courtes, une audience plus stricte et des contrôles réseau additionnels deviennent obligatoires. Une durée courte réduit la fenêtre de rejeu ; elle ne lie pas le jeton à son émetteur légitime.

Un reçu lié au déploiement réel

Le reçu d’exception de capacité devrait conserver les éléments suivants :

Champ du reçu Preuve à conserver
Capacité d’émission Plateforme, émetteur, version exacte, possibilité de produire plusieurs justificatifs
Maîtrise de l’audience Possibilité de demander ou d’influencer aud, avec preuve API ou configuration
Usage prévu API de plateforme, ressource interne, fédération ou ressource externe
Identité du justificatif Empreinte non secrète ou génération, jamais la valeur porteuse
Graphe des récepteurs Tous les accepteurs et les chemins de présentation entre eux
Durée TTL demandé et obtenu, renouvellement, révocation ou invalidation
Portée d’accès Composants, montages, sidecars, proxys, journaux et sorties pouvant le voir
Validation Émetteur, audience, type, preuve de possession et contrôles réseau à chaque récepteur
Motif d’exception Capacité absente et raison pour laquelle la séparation est impossible
Compensation Durée, restriction d’accès, réseau, surveillance et alerte
Réexamen Responsable, date de décision, prochaine revue, déclencheur de correction et sortie

L’empreinte doit être un identifiant à sens unique et non secret. Le reçu ne doit jamais stocker le bearer token dans un ticket. Il sert à relier une décision de risque à une génération de justificatif, à des récepteurs et à des contrôles précis.

Il doit aussi séparer « impossible » de « non réalisé ». Si l’émetteur sait fournir des jetons distincts mais qu’une intégration les réutilise par commodité, l’exception de capacité ne s’applique pas. Si une mise à jour ajoute le contrôle d’audience, la condition de sortie est atteinte. Sans échéance de réexamen, une exception provisoire devient facilement une architecture permanente.

L’article précédent de BTW, A Workload Credential Is Not the Workload, suivait huit preuves du démarrage au résultat. Le présent texte reste volontairement plus étroit : quels récepteurs peuvent parler avec ce bearer token précis, et auprès de qui ?

Sources et limites

Les sources principales sont la fiche Datatracker de la révision 07, l’historique du document, le texte immuable de la révision 07 et celui de la révision 06. La séparation entre artefact de coordination et réalité opérée reprend la discipline de Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

Ces sources établissent l’état documentaire, les exigences écrites et le mécanisme de risque. Elles ne prouvent aucun incident réel, ne recensent pas toutes les implémentations et n’établissent la non-conformité d’aucun opérateur nommé. Le reçu est une proposition éditoriale de Daniel Kade, pas une obligation du projet WIMSE.