GitHub OIDC

Bien qu’injecter les variables AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY via les secrets GitHub soit une pratique très répandue, il s’agit d’une approche sous-optimale. À la place, le protocole OIDC devrait être utilisé pour construire des pipelines beaucoup plus sécurisés. Ce tutoriel sera très concret et pratique.

Obtenir le jeton OIDC

Cela est déjà documenté dans la documentation officielle, mais en résumé : vous pouvez demander à GitHub de générer un ou plusieurs jetons pour l’exécution d’un job. Le champ audience doit représenter le système externe auquel le jeton est destiné. Dans notre cas, STS fait référence à AWS Secure Token Service.

Échanger le jeton OIDC

Même si l’étape précédente est intéressante à comprendre, nous vous recommandons de ne pas la faire manuellement. Utilisez plutôt l’action GitHub officielle configure-aws-credentials. Celle-ci abstrait toutes les étapes liées à la création du jeton et à son échange via le Secure Token Service. Il suffit de fournir un rôle IAM existant, et le tour est joué !

Configuration côté AWS

La partie qui pose le plus souvent problème est la configuration côté AWS. Dans la console AWS, rendez-vous dans IAM > Fournisseurs d'identité (Identity providers) et créez-en un nouveau.

Si vous avez un doute sur l’URL à utiliser, ajoutez /.well-known/openid-configuration à la fin de l’URL — cela doit retourner un JSON. Tous les fournisseurs OIDC exposent leur configuration à ce point d’entrée. Pour GitHub, l’URL correcte est : https://token.actions.githubusercontent.com

Notez que le champ audience est en réalité arbitraire — il suffit simplement qu’il corresponde à la valeur utilisée à la fois dans GitHub et dans AWS, et qu’elle ait une signification claire pour vous.

Créer un rôle IAM

C’est ici que ça devient intéressant — vous pouvez maintenant créer un rôle IAM qui utilise le fournisseur d’identité que nous venons de créer comme entité de confiance.

Respectez toujours le principe du moindre privilège lorsque vous attribuez des permissions !

GitHub inclut une valeur sub dans le jeton OIDC, qui contient des informations comme l’organisation, le dépôt et la branche. C’est extrêmement puissant ! Cela signifie que vous pouvez créer des rôles IAM utilisables uniquement lorsqu’un pipeline s’exécute depuis une branche spécifique.

Par exemple, le rôle IAM responsable du déploiement vers production devrait inclure une condition qui limite son usage à la branche prod. Dans GitHub, vous pouvez ensuite activer des protections sur la branche prod, comme l’obligation de passer par des revues de code. En combinant la granularité des rôles IAM avec les protections de branches de GitHub, vous pouvez construire un pipeline DevOps à la fois très sécurisé et conforme.