Fédération d'identité de charge de travail : supprimer les secrets des pipelines sans ouvrir de brèche

Le principe

Une plateforme externe capable d'émettre des jetons OIDC (GitHub, Azure DevOps, un cluster Kubernetes, un autre fournisseur cloud) fournit à chaque exécution un jeton signé décrivant la charge de travail. L'application l'échange contre un jeton d'accès Entra ID. Côté Entra ID, on déclare sur l'inscription d'application, ou sur une identité managée affectée par l'utilisateur, une information d'identification fédérée composée de trois éléments :

• L'émetteur : l'URL du fournisseur OIDC ;
• Le sujet : la valeur exacte attendue dans la revendication sub du jeton externe ;
• L'audience : généralement api://AzureADTokenExchange.

Aucun secret n'est stocké, et les jetons externes ont une durée de vie courte. Tout repose donc sur la précision de la correspondance entre émetteur et sujet.

GitHub Actions : le sujet fait tout

Pour GitHub, le sujet décrit le contexte d'exécution du workflow. Selon la configuration, il peut désigner une branche, une étiquette, un environnement ou un événement de pull request. Les pièges les plus fréquents :

1. Faire confiance aux pull requests : un sujet de type pull request peut être obtenu par un workflow déclenché depuis une contribution, dont le code n'a pas été relu ;
2. Faire confiance à un environnement non protégé : un sujet d'environnement n'a de valeur que si l'environnement impose des règles de protection, comme des approbateurs ou des branches autorisées ;
3. Faire confiance à une branche que tout le monde peut pousser : sans règle de protection, n'importe quel contributeur peut créer ou modifier la branche attendue ;
4. Personnaliser le modèle de sujet au niveau de l'organisation sans en mesurer l'effet : un sujet réduit au seul nom du dépôt élargit la confiance à tous ses workflows.

Azure DevOps

Les connexions de service Azure Resource Manager peuvent utiliser la fédération d'identité de charge de travail. Le sujet identifie l'organisation, le projet et la connexion de service. Le secret disparaît, mais le contrôle se déplace vers Azure DevOps : quels pipelines sont autorisés à utiliser la connexion, qui peut les modifier, quelles vérifications et approbations s'appliquent. Une connexion ouverte à tous les pipelines du projet reste un point faible.

Kubernetes

Avec l'identité de charge de travail sur AKS ou tout cluster exposant un émetteur OIDC, le sujet désigne un compte de service dans un espace de noms. Toute personne capable de créer un pod utilisant ce compte de service dans cet espace de noms obtient l'identité. Le RBAC Kubernetes devient alors la vraie frontière de sécurité.

Qui peut modifier la confiance

Ajouter une information d'identification fédérée à une application équivaut à lui ajouter un secret : un propriétaire de l'application ou un administrateur d'applications peut y déclarer un émetteur qu'il contrôle. Les modifications des informations d'identification fédérées doivent donc être surveillées dans les journaux d'audit, au même titre que l'ajout de secrets.

Ce qu'un audit vérifie

• L'inventaire des informations d'identification fédérées, avec émetteur et sujet.
• Les sujets trop larges : pull requests, environnements non protégés, correspondances génériques.
• Les droits Azure et Graph des applications fédérées.
• Les contrôles côté plateforme : protection des branches et environnements, autorisations des connexions de service, RBAC Kubernetes.
• La présence résiduelle de secrets sur les applications déjà fédérées.