Le rôle que n'importe quel dépôt peut endosser : une trust policy OIDC non épinglée
Le défi
Northwind permet à GitHub Actions de déployer sur AWS sans clés de longue durée : un workflow présente un jeton OIDC GitHub de courte durée et assume un rôle. Deux rôles font confiance à ce fournisseur. L'un sert à déployer le site marketing, l'autre dispose des droits d'administration complets sur le compte de production. Les deux vérifient que le jeton est bien un jeton GitHub Actions. Un seul vérifie aussi de quel dépôt provient le jeton. Lisez les deux trust policies et nommez le rôle que n'importe quel workflow de tout github.com peut assumer.
Ce que tu vas apprendre
- Expliquer ce que signifient les claims aud et sub d'un token OIDC GitHub
- Reconnaître que aud est une constante partagée qui ne prouve rien sur le dépôt
- Identifier une trust policy sans condition sur sub comme ouverte de façon critique
- Décrire le risque des wildcards StringLike sur sub et ref
- Retenir que la confiance doit se resserrer à mesure que les privilèges du rôle augmentent
Compétences testées
Prérequis
- Ce qu'est un rôle IAM et une trust policy
- Le principe de la fédération OIDC pour la CI
Comment ça marche
La CI sans clé fonctionne ainsi : un workflow présente un token OIDC de courte durée et assume un rôle AWS. La trust policy du rôle décide qui peut le faire, c'est donc toute la frontière.
La claim aud d'un token GitHub a la même valeur pour chaque exécution de GitHub Actions, partout ; la vérifier prouve seulement que l'appelant est un workflow GitHub quelconque. La claim sub est celle qui nomme le dépôt et la ref. Une trust policy qui vérifie aud mais pas sub acceptera un token émis par un workflow de n'importe quel dépôt sur github.com, y compris un dépôt appartenant à l'attaquant.
Le rôle doit donc épingler sub aux dépôts et refs exacts autorisés, et traiter les wildcards avec prudence : repo:org/* admet n'importe quel dépôt de l'organisation, et une ref trop large admet n'importe quelle branche ou une pull request.
Erreurs fréquentes
- Répondre
northwind-site-deploy. Sa policy épinglesubà un seul dépôt et une seule branche, c'est donc la sûre. - Croire que la vérification de
audaide. Chaque token GitHub porte le mêmeaud; ce n'est pas un contrôle de périmètre. - Supposer qu'un attaquant ne peut pas obtenir de token valide. N'importe qui peut lancer Actions dans son propre dépôt et recevoir un véritable token OIDC GitHub.
- Voir le privilège comme la faille. Les droits admin aggravent la situation, mais le bug est la condition
submanquante.
Comment s'en protéger
Épinglez le subject, et gardez des privilèges proportionnels au périmètre.
- Ajoutez toujours une condition
sublistant les valeurs exactesrepo:org/name:ref:...autorisées. Ne vous reposez jamais suraudseul. - Préférez
StringEqualssur des subjects complets. Si vous devez utiliserStringLike, évitezrepo:org/*et les refs trop larges ; limitez-vous à des dépôts et branches nommés. - Séparez les privilèges faibles et élevés : un rôle de déploiement pour un site ne doit jamais avoir la même ouverture qu'un rôle admin, et les rôles admin exigent la confiance la plus stricte possible.
- Auditez chaque rôle web-identity à la recherche d'un
submanquant ou avec wildcard.