Résumé

  • Le projet draft-ietf-wimse-workload-identity-practices-06 décrit le remplacement de secrets statiques par des justificatifs émis par la plateforme, de courte durée et limités à un destinataire.
  • Une signature valide n’établit pas, à elle seule, l’instance exacte qui agit, l’exclusivité de la clé, l’extinction de toutes les copies, l’autorisation de l’opération ou son résultat.

Une amélioration réelle, une preuve limitée

Le projet Workload Identity Practices part d’un coût très concret : un mot de passe, une clé API ou un secret OAuth installé dans une application doit être distribué, protégé puis renouvelé. Plus sa durée est longue, plus le vol permet une usurpation durable. La pratique émergente consiste à laisser la plateforme observer la charge de travail, émettre un justificatif, puis autoriser son échange contre un jeton adapté à une ressource extérieure.

Cette convergence ne signifie pas uniformité. Kubernetes projette des jetons de comptes de service. SPIFFE distribue des X509-SVID ou JWT-SVID par une API locale. Les clouds exposent des services de métadonnées ou des STS. Les maillages de services remettent souvent la clé au proxy plutôt qu’à l’application. Le document cartographie ces pratiques et leurs risques.

Il faut d’abord préserver son statut exact. Selon la fiche Datatracker, la révision 06 est un Internet-Draft actif, de statut visé Informational, soumis à l’IESG et placé en « AD Evaluation::Revised I-D Needed ». Ce n’est ni un RFC, ni une preuve d’adoption, ni une certification de déploiement.

L’amorçage doit laisser sa propre trace

La première décision se produit avant le jeton. La plateforme inspecte un environnement et des attributs pour décider quelle identité remettre. La qualité de cette décision dépend de ce qui est réellement observé : adresse ou machine partagée, UID du processus, métadonnées noyau, cgroup, libellés de l’orchestrateur, image ou dépôt associé.

SPIFFE résout le paradoxe du premier secret en permettant à la Workload API d’identifier son appelant hors bande. Mais une sélection fondée seulement sur le nœud ouvre l’identité à davantage de processus qu’une sélection liée à une instance. Il faut donc un reçu d’amorçage qui conserve l’émetteur, les attributs vus, les versions de l’attesteur et de la politique, l’instant et la décision. La signature ultérieure ne recrée pas ces faits.

Le compte n’est pas l’instance

Dans Kubernetes, la documentation des comptes de service distingue TokenRequest, jetons liés et validation. Le kubelet demande les jetons prévus par la configuration du Pod et les remet aux conteneurs. Le jeton peut nommer le namespace, le compte de service, le Pod et le nœud.

Ces claims sont une photographie signée, non un flux continu. Le Pod peut disparaître, une réplique le remplacer, la politique changer ou le jeton survivre à l’instance. La validation hors ligne prouve la signature et les claims. Elle ne demande pas si l’objet existe encore. Le projet précise que l’invalidation liée à la suppression n’est détectée que par TokenReview.

Le reçu d’exécution doit donc désigner l’instance précise, son état de cycle de vie, l’époque de planification et de politique, ainsi que l’instant de vérification. Un sub partagé par plusieurs répliques ne suffit pas.

Émission et livraison ne sont pas synonymes

Un émetteur peut produire les bons octets sans que le bon consommateur les charge. Le projet compare le fichier, l’API locale et la variable d’environnement. Pour le fichier, un remplacement atomique évite qu’une application lise une écriture partielle. Pour l’API locale, une socket Unix ou une adresse link-local permet la remise et le renouvellement à la demande. La variable d’environnement reste statique et se propage facilement aux journaux ou outils de diagnostic ; le projet l’interdit en production lorsqu’une autre voie existe.

Cependant, un rename atomique n’oblige pas chaque processus à rouvrir le fichier. Une application peut conserver l’ancien contenu en mémoire ou via un descripteur. Une réponse de l’API locale ne prouve pas l’absence de SSRF, d’écoute privilégiée ou de divulgation par l’application compromise. Le reçu de livraison doit lier canal, instance, empreinte du justificatif et accusé de réception.

La possession n’est pas l’exclusivité

Un bearer token peut être rejoué par quiconque le vole avant son expiration. Le projet recommande donc une preuve de possession lorsqu’elle est disponible. Une authentification X.509 démontre l’usage de la clé privée pendant l’échange ; un JWT lié à une clé impose une seconde preuve. RFC 8705 décrit une liaison OAuth par certificat TLS mutuel.

Cette preuve reste locale à l’échange. Elle ne démontre pas que la clé n’a jamais été copiée, qu’un seul processus peut l’utiliser, ni que ce processus reste conforme à l’état observé lors de l’amorçage. Un sidecar, un agent de nœud ou une interface HSM peut agir sans exporter la clé. La garde exclusive exige des données distinctes sur la génération, le stockage, les chemins d’appel et la destruction.

Le destinataire n’accorde pas l’opération

Le projet recommande un justificatif par ressource ou fournisseur d’identité et, pour un JWT, une audience unique. Réutiliser un jeton destiné à l’API Kubernetes pour une fédération externe mélange les frontières de confiance. La limitation réduit la surface d’abus.

Elle n’est pourtant pas une autorisation métier. aud dit quel vérificateur peut accepter le jeton ; il ne dit pas si la suppression, la signature ou le paiement est permis. RFC 7521 fournit le cadre des assertions OAuth et RFC 7523 le profil JWT bearer. Le traitement réussi d’une assertion ne dispense jamais la ressource d’évaluer l’opération exacte et son état courant.

La frontière avec l’Article BTW antérieur sur l’OAuth agentique est nette. Celui-ci traitait l’autorité sur les arguments produits par un modèle au premier point d’effet. Le présent Article porte sur la chaîne antérieure : amorçage, instance, émission, remise, possession, rotation et disparition du justificatif.

La rotation est un état distribué

Une courte durée diminue la fenêtre d’exploitation ; elle ne révoque pas instantanément. Le projet conseille d’émettre le nouveau secret avant d’invalider l’ancien afin d’éviter une interruption. Cette période de chevauchement est volontaire. Une application, un pool de connexions, un proxy ou une file de reprise peut continuer d’employer l’ancienne valeur.

Les fichiers durables, sauvegardes, instantanés et images peuvent aussi conserver des copies. Un montage en mémoire réduit ce risque sans démontrer que tous les journaux et caches sont propres. Pour chaque instance arrêtée ou supprimée, l’émetteur devrait invalider le justificatif et proposer une interrogation de statut ; le mécanisme concret reste hors du périmètre du projet.

Le mot « tourné » doit donc être décomposé en quatre preuves : nouvelle émission, adoption par les consommateurs prévus, rejet ou expiration de l’ancien justificatif, vidange des caches et instances connus.

Authentifier, exécuter, constater

Les projets WIMSE sur l’architecture, les justificatifs, les signatures HTTP et TLS mutuel renforcent des pièces voisines. Aucun ne prouve qu’une opération applicative a produit son effet.

Une ressource peut valider émetteur, durée, audience, type, possession et claims, puis refuser selon sa politique. Elle peut accepter avant d’échouer lors du commit. Un proxy partagé peut s’authentifier tout en représentant plusieurs charges. Le service qui effectue l’action doit produire un reçu de requête canonique, de décision, de transaction et de commit. Le système capable d’observer le résultat doit ensuite fournir un reçu distinct.

La distinction de Heng Lu entre couche réelle et couche symbolique s’applique directement : le jeton et le voyant vert signifient quelque chose, mais la réalité est l’état exécuté et observé. Les principes de spécification minimale et de vérification locale et de primauté du code en fonctionnement conduisent à garder chaque preuve auprès du système qui peut réellement la vérifier.

La bonne architecture n’est pas un jeton universel. C’est une chaîne de huit reçus : observation d’amorçage, liaison à l’instance, émission et remise, possession, audience et permission, rotation et invalidation, exécution, résultat. Elle permet de localiser un échec sans inventer une certitude générale.