GitHub Actions OIDC : sécuriser les déploiements cloud

Les credentials cloud persistants stockés dans les secrets CI sont difficiles à faire tourner et précieux à voler. GitHub Actions OIDC les remplace par une fédération courte : un job prouve son identité de workflow et reçoit un accès cloud temporaire.

OIDC supprime un problème de secret, pas la conception de la confiance. Un rôle trop large, accepté pour n’importe quel dépôt ou branche, transforme la compromission d’un workflow en brèche cloud.

Fonctionnement de la fédération

La documentation OIDC de GitHub décrit un workflow qui demande un jeton signé à GitHub puis le présente au fournisseur cloud. Celui-ci valide les claims et émet des credentials temporaires.

Les claims importants incluent souvent :

• issuer ;
• audience ;
• subject ;
• dépôt et propriétaire ;
• branche, tag ou environnement ;
• référence du workflow ;
• identifiants du run.

Les fournisseurs diffèrent. Construisez la confiance autour de claims immuables et spécifiques.

Contraindre la relation de confiance

Évitez une condition qui autorise chaque branche ou dépôt de l’organisation. Liez les rôles puissants à :

• un dépôt ou identifiant stable ;
• un environnement de production protégé ;
• une branche ou un tag approuvé ;
• un workflow revu ;
• l’audience attendue ;
• des contraintes d’organisation.

Créez des rôles séparés pour build, preview, staging et production, chacun avec permissions et durée minimales.

Protéger le workflow

L’attaquant n’a pas besoin de voler une clé s’il peut modifier le workflow autorisé.

Contrôles :

• protection de branche et revue ;
• CODEOWNERS sur les workflows ;
• actions tierces épinglées ;
• permissions minimales du token GitHub ;
• aucun privilège dans les jobs de PR non fiable ;
• approbation d’environnement pour la production ;
• runners isolés et éphémères ;
• workflows réutilisables restreints.

Accordez id-token write uniquement au job de fédération. Cette permission crée le jeton ; le cloud n’est accessible que si sa politique fait confiance aux claims.

Valider les claims et tester l’échec

Journalisez les claims utilisés sans exposer les jetons. Vérifiez que branches fonctionnelles, forks, autres dépôts et workflows modifiés ne peuvent pas assumer le rôle.

Créez des tests négatifs :

1. branche non approuvée vers la production ;
2. pull request de fork vers tout rôle cloud ;
3. mauvaise audience ;
4. autre workflow appelant le job de déploiement ;
5. rejeu d’un jeton expiré.

La sécurité dépend autant des chemins refusés que du déploiement réussi.

Garde-fous runtime et réseau

Des credentials courts peuvent causer des dégâts pendant leur validité. Appliquez least privilege côté cloud, politiques de ressources, frontières réseau, détection d’anomalie et audit. Restreignez l’egress CI et surveillez les destinations inattendues avant la fédération.

Une dépendance malveillante dans le même job peut demander ou voler le jeton. Séparez installation, build et déploiement. Suivez la défense de la supply chain GitHub Actions.

Réponse à incident

Après abus, désactivez ou resserrez la confiance, stoppez le workflow et révoquez les sessions cloud. Préservez logs du run, claims, audit cloud, commits, versions d’actions et preuves du runner.

Recherchez les sessions partageant dépôt, workflow, subject et infrastructure source. Faites tourner les secrets persistants restants ; les migrations OIDC laissent souvent des clés anciennes.

Métriques

Suivez secrets cloud persistants, rôles fédérés, wildcards de confiance, jobs avec id-token, déploiements via environnements approuvés, refus et délai de traçage entre session cloud et run.

Conclusion

GitHub Actions OIDC remplace les secrets stockés par une identité de workload courte et attribuable. Sa sûreté dépend de claims précis, de workflows protégés et de rôles minimaux. Associez la fédération à la gouvernance des identités non humaines afin que chaque identité ait propriétaire, périmètre et cycle de vie.