GitLab OIDC

Bien qu’injecter les variables AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY via les variables GitLab soit une pratique très courante, il s’agit d’une approche sous-optimale, même en utilisant le drapeau Protected. À la place, le protocole OIDC devrait être utilisé pour construire des pipelines bien plus sécurisés. Ce tutoriel sera très concret et pratique.

Obtenir le jeton OIDC

C’est déjà bien documenté dans la documentation officielle, mais en résumé : vous pouvez demander à GitLab de générer un ou plusieurs jetons pour l’exécution d’un job. Le nom du jeton peut être librement choisi — idéalement, utilisez un nom parlant. Le champ audience doit représenter le système externe auquel le jeton est destiné. Dans ce cas, STS fait référence à AWS Secure Token Service.

Échanger le jeton OIDC

L’étape suivante consiste à échanger le jeton OIDC contre des identifiants temporaires AWS. Cela se fait via STS (Secure Token Service). La syntaxe est un peu particulière, mais l’opération reste assez simple. Une fois l’échange effectué, vous pourrez utiliser l’AWS CLI comme d’habitude.

Configuration côté AWS

La partie qui pose le plus souvent problème est la configuration côté AWS. Dans la console AWS, allez 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 GitLab, l’URL est https://gitlab.com

Notez que le champ audience est en réalité arbitraire — il suffit simplement qu’il corresponde entre GitLab et AWS, et qu’il ait une valeur significative pour vous.

Créer un rôle IAM

C’est la partie intéressante — 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 lors de l’ajout des permissions !

GitLab inclut une valeur sub dans le jeton OIDC qui contient des informations sur le groupe, le projet et la branche. C’est extrêmement puissant ! Cela signifie que vous pouvez créer des rôles IAM qui ne sont utilisables que lors de l’exécution depuis une branche spécifique.

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