Configurer la fédération d'identité de charge de travail avec des pipelines de déploiement

Ce guide explique comment utiliser la fédération d'identité de charge de travail pour permettre aux pipelines de déploiement de s'authentifier auprès de Google Cloud.

Selon le système CI/CD que vous utilisez, vos pipelines de déploiement peuvent avoir accès à des identifiants ambiants spécifiques à l'environnement. Par exemple :

Les pipelines Azure DevOps peuvent utiliser une connexion de service de fédération d'identité de charge de travail Microsoft Entra pour obtenir un jeton d'ID qui identifie de manière unique le projet Azure DevOps.
Les workflows GitHub Actions peuvent obtenir un jeton OIDC GitHub qui identifie de manière unique le workflow et son dépôt.
GitLab SaaS permet aux tâches CI/CD d'accéder à un jeton d'ID qui identifie de manière unique la tâche ainsi que son projet, son environnement et son dépôt.
Terraform Cloud peut fournir un jeton OIDC à votre configuration Terraform qui identifie de manière unique l'espace de travail et l'environnement.

Vous pouvez configurer vos pipelines de déploiement de sorte qu'ils utilisent ces identifiants pour s'authentifier auprès de Google Cloud à l'aide de la fédération d'identité de charge de travail. Cette approche élimine les tâches de maintenance et de sécurité associées aux clés de compte de service.

Avant de commencer

Configurer l'authentification

Select the tab for how you plan to use the samples on this page:

Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Python

Pour utiliser les exemples Python de cette page dans un environnement de développement local, installez et initialisez gcloud CLI, puis configurez le service Identifiants par défaut de l'application à l'aide de vos identifiants utilisateur.

Install the Google Cloud CLI.
To initialize the gcloud CLI, run the following command:
```
gcloud init
```
If you're using a local shell, then create local authentication credentials for your user account:
```
gcloud auth application-default login
```
You don't need to do this if you're using Cloud Shell.

Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local dans la documentation sur l'authentification Google Cloud.

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer la fédération d'identité de charge de travail, demandez à votre administrateur de vous accorder le rôle IAM Administrateur de pool d'identités de charge de travail (roles/iam.workloadIdentityPoolAdmin) sur le projet. Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Le rôle de base IAM "Propriétaire" (roles/owner) inclut également des autorisations permettant de configurer la fédération d'identité. Les rôles de base ne doivent pas être attribués dans un environnement de production, mais ils peuvent être attribués dans un environnement de développement ou de test.

Préparer votre fournisseur d'identité externe

Azure DevOps

Pour permettre à un pipeline Azure DevOps de s'authentifier auprès de Google Cloud, vous devez d'abord configurer une connexion de service pour Azure Resource Manager. Cette connexion permet au pipeline d'obtenir un jeton d'ID, qu'il peut ensuite échanger contre des identifiants Google Cloud.

Pour créer une connexion de service pour Azure Resource Manager, procédez comme suit :

Dans Azure DevOps, ouvrez votre projet et accédez à Paramètres du projet.
Accédez à Pipelines > Connexions de service.
Cliquez sur Créer une connexion de service.
Sélectionnez Azure Resource Manager.
Cliquez sur Suivant.
Sélectionnez Fédération d'identité de charge de travail (automatique).
Cliquez sur Suivant.
Configurez les paramètres suivants :
- Niveau d'accès : sélectionnez un abonnement.
  
  Vous devez sélectionner un abonnement même si vous ne prévoyez pas d'utiliser la connexion de service pour accéder aux ressources Azure.
- Nom de la connexion au service : saisissez un nom tel que google-cloud.
Cliquez sur Enregistrer.

Lors d'une prochaine étape, vous aurez besoin de l'identifiant d'émetteur et de sujet de la connexion de service. Pour rechercher ces détails, procédez comme suit :

Cliquez sur la connexion de service que vous venez de créer.
Cliquez sur Gérer le compte principal de service.
Accédez à Certificat et secrets > Identifiants fédérés.
Cliquez sur l'identifiant fédéré.
Sur la page Modifier un identifiant, recherchez les identifiants suivants :
- Émetteur : identifie de manière unique votre organisation Azure DevOps
- Identifiant de sujet : identifie de manière unique la connexion au service

Azure DevOps accorde automatiquement l'accès à l'abonnement que vous avez sélectionné comme champ d'application au compte principal de service associé à votre nouvelle connexion de service. Comme vous ne prévoyez pas d'utiliser la connexion de service pour accéder aux ressources Azure, vous pouvez révoquer cet accès en procédant comme suit :

Sur le portail Azure, ouvrez l'abonnement que vous avez sélectionné comme champ d'application.
Accédez à Contrôle des accès (IAM) > Attributions de rôles.
Recherchez l'attribution de rôle pour la connexion de service et supprimez-la.

GitHub Actions

Vous n'avez pas de modifications de configuration à effectuer dans votre compte GitHub.

Après avoir configuré un pool d'identités de charge de travail pour approuver votre dépôt GitHub, vous pouvez autoriser les workflows de ce dépôt à utiliser leur jeton OIDC GitHub pour obtenir des identifiants Google Cloud éphémères.

GitLab SaaS

Vous n'avez pas de modifications de configuration à effectuer dans votre compte GitLab.

Après avoir configuré un pool d'identités de charge de travail pour approuver votre groupe GitLab, vous pouvez activer la fédération d'identité de charge de travail pour des jobs CI/CD individuels.

Terraform Cloud

Vous n'avez pas besoin de modifier la configuration dans votre compte Terraform Cloud.

Après avoir configuré un pool d'identités de charge de travail pour approuver Terraform Cloud, vous pouvez activer la fédération d'identité de charge de travail pour des espaces de travail individuels.

Configurer la fédération d'identité de charge de travail

Vous devez effectuer ces étapes pour chaque organisation GitHub, groupe GitLab ou organisation Terraform Cloud.

Pour commencer à configurer la fédération d'identité de charge de travail, procédez comme suit :

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

utiliser un projet dédié pour gérer les pools et les fournisseurs d'identités de charge de travail

Make sure that billing is enabled for your Google Cloud project.

Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

Enable the APIs

Définir un mappage d'attributs

Les identifiants spécifiques à l'environnement de votre pipeline de déploiement contiennent plusieurs attributs. Vous devez choisir celui que vous souhaitez utiliser en tant qu'identifiant d'objet (google.subject) dans Google Cloud.

Vous pouvez éventuellement mapper d'autres attributs. Vous pouvez ensuite faire référence à ces attributs supplémentaires lorsque vous accordez l'accès aux ressources.

Azure DevOps

Le jeton d'ID Azure DevOps inclut une revendication sub qui contient l'identifiant de sujet de votre connexion de service. L'identifiant de sujet utilise le format suivant :

sc://ORGANIZATION/PROJECT/CONNECTION

Utilisez le mappage d'attributs suivant pour mapper cet identifiant sur google.subject :

google.subject=assertion.sub

GitHub Actions

Vos mappages d'attributs peuvent utiliser n'importe quelle revendication du jeton OIDC GitHub Actions. Ces clés de revendication de jeton et leurs valeurs sont contrôlées par GitHub. Vous devez au moins mapper google.subject sur assertion.sub, ce qui correspond à l'objet du jeton OIDC pour les actions GitHub :

google.subject=assertion.sub

La valeur de l'objet du jeton OIDC pour GitHub Actions peut varier en fonction de l'événement source. Les autres attributs de revendication peuvent inclure :

repository : contient le nom du propriétaire et du dépôt, par exemple "google/guava".
repository_id : contient l'ID de dépôt unique, par exemple "20300177".
repository_owner : contient le propriétaire, qui peut être un nom d'utilisateur ou le nom d'une organisation GitHub, par exemple "google".
repository_owner_id : contient l'ID de propriétaire unique, par exemple "1342004".

Cette liste est un sous-ensemble des revendications possibles. Consultez la documentation GitHub sur les exemples de revendications pour obtenir la liste complète. Assurez-vous de mapper toutes les revendications que vous prévoyez d'utiliser en tant que conditions d'attribut ou dans le cadre d'une condition principalSet future.

GitLab SaaS

Vos mappages d'attributs peuvent utiliser les revendications intégrées au jeton d'ID GitLab en tant qu'attributs sources, y compris les suivantes :

sub : nom du projet et référence Git (par exemple, project_path:groupname/projectname:ref_type:branch:ref:main)
namespace_id : ID de groupe unique.
project_id : ID de projet unique.
user_id : ID utilisateur unique.
environment : environnement auquel la tâche s'applique.
ref_path : référence Git (par exemple, refs/heads/main)

Le mappage d'attributs suivant définit google.subject sur la revendication sub à partir du jeton d'ID GitLab. Comme la revendication sub contient à la fois le nom du projet et la référence Git, ce mappage vous permet de contrôler l'accès par dépôt et par branche :

google.subject=assertion.sub

Le contrôle des accès par dépôt et par branche peut être utile si certaines branches (par exemple main) nécessitent un accès différent aux ressources par rapport à d'autres branches (par exemple des branches de fonctionnalités).

Dans certains cas, il peut être suffisant de différencier l'accès par projet ou par groupe. Le mappage suivant inclut donc deux attributs supplémentaires contenant les fichiers GitLab project_id et namespace_id :

google.subject=assertion.sub
attribute.project_id=assertion.project_id
attribute.namespace_id=assertion.namespace_id

Terraform Cloud

Vos mappages d'attributs peuvent utiliser les revendications intégrées dans le jeton OIDC Terraform Cloud, y compris :

terraform_organization_id : contient l'ID unique de l'organisation, par exemple org-xxxxxxxxxxxxxxxx.
terraform_workspace_id : contient l'ID unique de l'espace de travail, par exemple ws-xxxxxxxxxxxxxxxx.
terraform_workspace_name : contient le nom à afficher de l'espace de travail.
sub : contient le nom à afficher de l'organisation, de l'espace de travail et de la phase (par exemple, organization:example-org:workspace:example-workspace:run_phase:apply).

Le mappage d'attributs suivant définit google.subject sur la revendication terraform_workspace_id à partir du jeton OIDC Terraform Cloud :

google.subject=assertion.terraform_workspace_id

Ce mappage vous permet de contrôler l'accès aux ressources Google Cloud par espace de travail.

Définir une condition d'attribut

Les conditions d'attribut sont des expressions CEL qui peuvent vérifier les attributs d'assertion et les attributs cibles. Si la condition d'attribut renvoie true pour un identifiant donné, celui-ci est accepté. Dans le cas contraire, l'identifiant est rejeté. Vous devez disposer d'un mappage d'attributs pour tous les champs de condition d'attribut.

Azure DevOps

Vous pouvez éventuellement utiliser une condition d'attribut pour limiter l'accès à certaines connexions de service. Par exemple, la condition suivante limite l'accès aux connexions dans un projet Azure DevOps donné :

assertion.sub.startsWith('sc://ORGANIZATION/PROJECT/')

Remplacez les éléments suivants :

ORGANIZATION : nom de votre organisation Azure DevOps
PROJECT : nom de votre projet Azure DevOps

GitHub Actions

Utilisez la condition d'attribut suivante pour restreindre l'accès aux jetons émis par votre organisation GitHub :

assertion.repository_owner=='ORGANIZATION'

Remplacez ORGANIZATION par le nom de votre organisation GitHub.

Vous pouvez éventuellement étendre la condition d'attribut pour limiter l'accès à un sous-ensemble de workflows ou de branches. Par exemple, la condition suivante limite l'accès aux workflows qui utilisent la branche Git main :

assertion.repository_owner=='ORGANIZATION' && assertion.ref=='refs/heads/main'

GitLab SaaS

Utilisez la condition d'attribut suivante pour limiter l'accès aux jetons émis par votre groupe GitLab.

assertion.namespace_id=='GROUP_ID'

Remplacez GROUP_ID par l'ID de groupe affiché sur la page d'accueil de votre groupe GitLab.

Étendez éventuellement la condition d'attribut pour limiter l'accès à un sous-ensemble de projets, de branches ou d'environnements. Par exemple, la condition suivante limite l'accès aux tâches qui utilisent l'environnement production :

assertion.namespace_id=='GROUP_ID' && assertion.environment=='production'

Terraform Cloud

Utilisez la condition d'attribut suivante pour restreindre l'accès aux jetons émis par votre organisation Terraform Cloud :

assertion.terraform_organization_id=='ORGANIZATION_ID'

Remplacez ORGANIZATION_ID par l'ID unique de votre organisation, par exemple org-xxxxxxxxxxxxxxxx. Étendez éventuellement la condition d'attribut pour limiter l'accès à un sous-ensemble de workflows ou de branches. Par exemple, la condition d'attribut suivante limite l'accès à un espace de travail spécifique :

assertion.terraform_organization_id=='ORGANIZATION_ID' && terraform_workspace_id=='WORKSPACE_ID'

Créer le pool d'identité de charge de travail et le fournisseur

Vous avez maintenant collecté toutes les informations nécessaires pour créer un pool d'identités de charge de travail et un fournisseur :

Console

Dans la console Google Cloud, accédez à la page Nouveau fournisseur et pool de charges de travail.

Accéder au nouveau fournisseur de charges de travail et au pool
Sous Créer un pool d'identités, saisissez les informations suivantes :
- Nom : nom du pool. Le nom est également utilisé comme ID du pool. Vous ne pourrez pas modifier l'ID du pool par la suite.
- Description : texte décrivant l'objectif du pool.
Cliquez sur Continuer.
Configurez les paramètres du fournisseur :
Azure DevOps
- Sélectionner un fournisseur : OpenID Connect (OIDC).
- Nom du fournisseur : nom du projet Azure DevOps ou nom personnalisé
- ID du fournisseur : nom du projet Azure DevOps ou ID personnalisé. Vous ne pourrez pas modifier l'ID du fournisseur par la suite.
- URL de l'émetteur : émetteur de la connexion de service que vous avez recherché précédemment
- Audiences : sélectionnez Audiences autorisées et collez la valeur suivante
  api://AzureADTokenExchange
GitHub Actions
- Sélectionner un fournisseur : OpenID Connect (OIDC).
- Nom du fournisseur : nom du fournisseur.
- ID du fournisseur : ID du fournisseur. Vous ne pourrez pas modifier l'ID du fournisseur par la suite.
- URL de l'émetteur : https://token.actions.githubusercontent.com/
- Audiences : Audience par défaut
GitLab SaaS
- Sélectionner un fournisseur : OpenID Connect (OIDC).
- Nom du fournisseur : nom du fournisseur.
- ID du fournisseur : ID du fournisseur. Vous ne pourrez pas modifier l'ID du fournisseur par la suite.
- URL de l'émetteur : https://gitlab.com
- Audiences : Audience par défaut
Terraform Cloud
- Sélectionner un fournisseur : OpenID Connect (OIDC).
- Nom du fournisseur : nom du fournisseur.
- ID du fournisseur : ID du fournisseur. Vous ne pourrez pas modifier l'ID du fournisseur par la suite.
- URL de l'émetteur : https://app.terraform.io
- Audiences : Audience par défaut
Cliquez sur Continuer.
Sous Configurer les attributs de fournisseur, ajoutez les mappages d'attributs que vous avez identifiés précédemment.
Sous Conditions d'attribut, saisissez la condition d'attribut que vous avez identifiée précédemment.
Cliquez sur Enregistrer pour créer le pool d'identités de charge de travail et le fournisseur.

gcloud

Créez un pool d'identités de charge de travail :
```
gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
Remplacez les valeurs suivantes :
- POOL_ID : ID unique du pool
- DISPLAY_NAME : nom du pool
- DESCRIPTION : description du pool. Cette description apparaît lorsque vous accordez l'accès aux identités du pool.
Ajoutez un fournisseur de pool d'identités de charge de travail :
Azure DevOps
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Remplacez les valeurs suivantes :
- PROVIDER_ID : nom du projet Azure DevOps ou ID personnalisé du fournisseur
- POOL_ID : ID du pool
- ISSUER : émetteur de connexion de service que vous avez recherché précédemment
- MAPPINGS : liste des mappages d'attributs que vous avez identifiés précédemment, séparés par une virgule.
- CONDITIONS : condition d'attribut que vous avez identifiée précédemment.
GitHub Actions
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://token.actions.githubusercontent.com/" \
    --allowed-audiences="api://AzureADTokenExchange" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Remplacez les valeurs suivantes :
- PROVIDER_ID : ID unique du fournisseur.
- POOL_ID : ID du pool
- MAPPINGS : liste des mappages d'attributs que vous avez identifiés précédemment, séparés par une virgule.
- CONDITIONS : condition d'attribut que vous avez identifiée précédemment.
GitLab SaaS
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://gitlab.com" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Remplacez les valeurs suivantes :
- PROVIDER_ID : ID unique du fournisseur.
- POOL_ID : ID du pool
- MAPPINGS : liste des mappages d'attributs que vous avez identifiés précédemment, séparés par une virgule.
- CONDITIONS : condition d'attribut que vous avez identifiée précédemment.
Terraform Cloud
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://app.terraform.io" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Remplacez les valeurs suivantes :
- PROVIDER_ID : ID unique du fournisseur.
- POOL_ID : ID du pool.
- MAPPINGS : liste des mappages d'attributs que vous avez identifiés précédemment, séparés par une virgule.
- CONDITIONS : condition d'attribut que vous avez identifiée précédemment.

Mettre à jour la condition d'attribut sur un fournisseur d'identité de charge de travail

Cette section explique comment mettre à jour la condition d'attribut sur un fournisseur de pool d'identités de charge de travail existant pour restreindre l'accès aux jetons émis par votre organisation GitHub, votre groupe GitLab ou votre organisation Terraform Cloud.

Pour trouver la condition d'attribut recommandée pour votre pipeline, consultez la section Définir une condition d'attribut.

Console

Dans la console Google Cloud, accédez à la page Pools d'identités de charge de travail.

Accéder aux pools d'identité de charge de travail
Recherchez le pool d'identités de charge de travail qui contient le fournisseur, puis cliquez sur l'icône Développer le nœud pour le pool.
Recherchez le fournisseur du pool d'identités de charge de travail que vous souhaitez modifier, puis cliquez sur Modifier.
Dans Conditions d'attribut, saisissez la condition d'attribut que vous avez identifiée précédemment.
Pour mettre à jour le pool et le fournisseur d'identités de charge de travail, cliquez sur Enregistrer.

gcloud

Pour mettre à jour le fournisseur du pool d'identités de charge de travail, exécutez la commande suivante :

gcloud iam workload-identity-pools providers update-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --attribute-condition="CONDITIONS"

Remplacez les valeurs suivantes :

PROVIDER_ID : ID unique du fournisseur.
POOL_ID : ID du pool
CONDITIONS : condition d'attribut que vous avez identifiée précédemment

Authentifier un pipeline de déploiement

Vous devez effectuer ces étapes pour chaque workflow GitHub Actions ou espace de travail Terraform Cloud.

Autoriser votre charge de travail externe à accéder aux ressources Google Cloud

Pour suivre les instructions ultérieures de ce guide, vous devez configurer l'emprunt d'identité du compte de service comme décrit dans cette section.

Pour autoriser votre charge de travail à accéder aux ressources Google Cloud, nous vous recommandons d'accorder un accès direct aux ressources au compte principal. Dans ce cas, le compte principal est l'utilisateur fédéré. Certains produits Google Cloud sont soumis aux limites de l'API Google Cloud. Si votre charge de travail appelle un point de terminaison d'API présentant une limite, vous pouvez emprunter l'identité d'un compte de service. Dans ce cas, le compte principal est le compte de service Google Cloud, qui agit en tant qu'identité. Vous accordez l'accès au compte de service sur la ressource.

Accès direct aux ressources

Vous pouvez accorder l'accès à une identité fédérée directement sur les ressources à l'aide de la console Google Cloud ou de gcloud CLI.

Console

Pour attribuer des rôles IAM directement sur une ressource à l'aide de la console Google Cloud, vous devez accéder à la page de la ressource, puis attribuer le rôle. L'exemple suivant montre comment accéder à la page Cloud Storage et accorder le rôle Lecteur des objets de l'espace de stockage (roles/storage.objectViewer) à une identité fédérée directement sur un bucket Cloud Storage.

Dans la console Google Cloud, accédez à la page Buckets Cloud Storage.
Accéder à la page "Buckets"
Dans la liste des buckets, cliquez sur le nom du bucket pour lequel vous souhaitez attribuer le rôle.
Sélectionnez l'onglet Autorisations en haut de la page.
Cliquez sur le bouton Accorder l'accès.

La boîte de dialogue Ajouter des entités principales s'affiche.
Dans le champ Nouveaux comptes principaux, saisissez une ou plusieurs identités nécessitant un accès au bucket.
Par sujet
```
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
```
Remplacez les éléments suivants :
- PROJECT_NUMBER : numéro de projet
- POOL_ID : ID du pool de charges de travail
- SUBJECT : sujet individuel mappé à partir de votre fournisseur d'identité (par exemple, administrator@example.com)
Par groupe
```
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
```
Remplacez les éléments suivants :
- PROJECT_NUMBER : numéro de projet
- WORKLOAD_POOL_ID : ID du pool de charges de travail
- GROUP : groupe mappé à partir de votre fournisseur d'identité (par exemple, administrator-group@example.com)
Par attribut
```
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
```
Remplacez les éléments suivants :
- PROJECT_NUMBER : numéro de projet
- WORKLOAD_POOL_ID : ID du pool de charges de travail
- ATTRIBUTE_NAME : l'un des attributs mappés à partir de votre fournisseur d'identité
- ATTRIBUTE_VALUE : valeur de l'attribut
Sélectionnez un ou plusieurs rôles dans le menu déroulant Select a role (Sélectionnez un rôle). Les rôles sélectionnés apparaissent dans le volet et sont accompagnés d'une brève description des autorisations auxquelles ils correspondent.
Cliquez sur Enregistrer.

gcloud

Pour accorder des rôles IAM sur une ressource d'un projet à l'aide de gcloud CLI, procédez comme suit :

Obtenez le numéro du projet dans lequel la ressource est définie.

gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)

Accordez l'accès à la ressource.

Pour utiliser gcloud CLI afin d'accorder le rôle Utilisateur Workload Identity (roles/iam.workloadIdentityUser) aux identités externes qui répondent à certains critères, exécutez la commande suivante.
Par sujet
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
```
Par groupe
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
```
Par attribut
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
```
Remplacez les éléments suivants :
- BUCKET_ID : bucket pour lequel vous souhaitez accorder l'accès.
- PROJECT_NUMBER : numéro du projet contenant le pool d'identités de charge de travail
- POOL_ID : ID du pool d'identités de charge de travail.
- SUBJECT : valeur attendue pour l'attribut que vous avez mappé sur google.subject.
- GROUP : valeur attendue pour l'attribut que vous avez mappé sur google.groups.
- ATTRIBUTE_NAME : nom d'un attribut personnalisé dans votre mappage d'attributs
- ATTRIBUTE_VALUE : valeur de l'attribut personnalisé dans votre mappage d'attributs
Vous pouvez attribuer des rôles sur n'importe quelle ressource Google Cloud compatible avec les stratégies d'autorisation IAM.

Remarque : Vous devez utiliser le numéro du projet, et non l'ID du projet, dans l'identifiant du membre.

Emprunter l'identité d'un compte de service

Pour créer un compte de service pour la charge de travail externe, procédez comme suit :
1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.
  Enable the APIs
2. Créez un compte de service qui représente la charge de travail. Il est préférable d'utiliser un compte de service dédié pour chaque charge de travail.
  
  Le compte de service ne doit pas obligatoirement se trouver dans le même projet que le pool d'identités de charge de travail.
3. Accordez au compte de service l'accès aux ressources auxquelles vous souhaitez que les identités externes accèdent.
4. Attribuez le rôle Utilisateur Workload Identity (roles/iam.workloadIdentityUser) au compte de service.
5. Créez un compte de service qui représente la charge de travail. Nous vous recommandons d'utiliser un compte de service dédié pour chaque charge de travail.
  
  Le compte de service ne doit pas obligatoirement se trouver dans le même projet que le pool d'identités de charge de travail, mais vous devez faire référence au projet qui contient le compte de service.
Pour accorder l'accès à une identité fédérée à l'aide de l'emprunt d'identité d'un compte de service en utilisant la console Google Cloud ou gcloud CLI, procédez comme suit :
Console
Pour attribuer des rôles IAM à une identité fédérée avec un compte de service à l'aide de la console Google Cloud, procédez comme suit :
1. Créez un compte de service servant d'identité à emprunter en procédant comme suit :
  1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.
    Enable the APIs
  2. Créez un compte de service qui représente l'identité de la charge de travail. Nous vous recommandons d'utiliser un compte de service dédié pour chaque charge de travail.
    
    Le compte de service ne doit pas obligatoirement se trouver dans le même projet que le pool d'identités de charge de travail, mais lorsque vous accordez l'accès IAM, vous devez faire référence au projet contenant le compte de service.
  3. Accordez au compte de service l'accès aux ressources auxquelles vous souhaitez que les identités externes accèdent.
2. Pour accorder l'accès à l'aide de l'emprunt d'identité d'un compte de service, procédez comme suit :
  1. Accédez à la page Pools d'identités de charge de travail.
    
    Accéder aux pools d'identité de charge de travail
  2. Sélectionnez Accorder l'accès.
  3. Dans la boîte de dialogue Accorder l'accès au compte de service, sélectionnez Accorder l'accès à l'aide de l'emprunt d'identité du compte de service.
  4. Dans la liste Comptes de service, sélectionnez le compte de service pour les identités externes à emprunter, puis procédez comme suit :
  5. Pour choisir les identités du pool qui peuvent emprunter l'identité du compte de service, effectuez l'une des actions suivantes :
    
    Pour n'autoriser que les identités spécifiques du pool d'identités de charge de travail à emprunter l'identité du compte de service, sélectionnez Uniquement les identités correspondant au filtre.
    
    Dans la liste Nom de l'attribut, sélectionnez l'attribut sur lequel vous souhaitez filtrer les données.
    
    Dans le champ Valeur d'attribut, saisissez la valeur attendue de l'attribut. Par exemple, si vous utilisez un mappage d'attribut google.subject=assertion.sub, définissez le nom de l'attribut sur subject et la valeur d'attribut sur la valeur de la revendication sub dans les jetons émis par votre fournisseur d'identité externe.
  6. Pour enregistrer la configuration, cliquez sur Enregistrer, puis sur Ignorer.
gcloud

Pour utiliser gcloud CLI afin d'accorder le rôle Utilisateur Workload Identity (roles/iam.workloadIdentityUser) aux identités externes qui répondent à certains critères, exécutez la commande suivante.
Par sujet

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
Par groupe

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
Par attribut

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
Remplacez les éléments suivants :
- SERVICE_ACCOUNT_EMAIL : adresse e-mail du compte de service
- PROJECT_NUMBER : numéro du projet contenant le pool d'identités de charge de travail
- POOL_ID : ID du pool d'identités de charge de travail.
- SUBJECT : valeur attendue pour l'attribut que vous avez mappé sur google.subject.
- GROUP : valeur attendue pour l'attribut que vous avez mappé sur google.groups.
- ATTRIBUTE_NAME : nom d'un attribut personnalisé dans votre mappage d'attributs
- ATTRIBUTE_VALUE : valeur de l'attribut personnalisé dans votre mappage d'attributs
Remarque : Vous devez utiliser le numéro du projet, et non l'ID du projet, dans l'identifiant du membre.

Configurer le pipeline de déploiement

Cette section explique comment utiliser la fédération d'identité de charge de travail dans votre pipeline de déploiement. Les instructions de cette section partent du principe que vos charges de travail utilisent l'emprunt d'identité du compte de service pour accéder aux ressources Google Cloud.

Azure DevOps

Modifiez votre fichier azure-pipelines.yml et ajoutez les éléments suivants à la configuration de votre job :

variables:
- name: Azure.WorkloadIdentity.Connection
  value: CONNECTION
- name: GoogleCloud.WorkloadIdentity.ProjectNumber
  value: PROJECT_NUMBER
- name: GoogleCloud.WorkloadIdentity.Pool
  value: POOL_ID
- name: GoogleCloud.WorkloadIdentity.Provider
  value: PROVIDER_ID
- name: GoogleCloud.WorkloadIdentity.ServiceAccount
  value: SERVICE_ACCOUNT_EMAIL
- name: GOOGLE_APPLICATION_CREDENTIALS
  value: $(Pipeline.Workspace)/.workload_identity.wlconfig

steps:
  - task: AzureCLI@2
    inputs:
      connectedServiceNameARM: $(Azure.WorkloadIdentity.Connection)
      addSpnToEnvironment: true
      scriptType: 'bash'
      scriptLocation: 'inlineScript'
      inlineScript: |
        echo $idToken > $(Pipeline.Workspace)/.workload_identity.jwt
        cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS
        {
          "type": "external_account",
          "audience": "//iam.googleapis.com/projects/$(GoogleCloud.WorkloadIdentity.ProjectNumber)/locations/global/workloadIdentityPools/$(GoogleCloud.WorkloadIdentity.Pool)/providers/$(GoogleCloud.WorkloadIdentity.Provider)",
          "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
          "token_url": "https://sts.googleapis.com/v1/token",
          "credential_source": {
            "file": "$(Pipeline.Workspace)/.workload_identity.jwt"
          },
          "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$(GoogleCloud.WorkloadIdentity.ServiceAccount):generateAccessToken"
        }
        EOF

Remplacez les valeurs suivantes :

CONNECTION : nom de votre connexion de service
PROJECT_NUMBER : numéro du projet contenant le pool d'identités de charge de travail
POOL_ID : ID du pool d'identités de charge de travail
PROVIDER_ID : ID du fournisseur du pool d'identités de charge de travail
SERVICE_ACCOUNT_EMAIL : adresse e-mail du compte de service.

La configuration effectue les opérations suivantes :

Elle utilise la tâche AzureCLI afin d'obtenir un jeton d'ID pour la connexion de service et le rend disponible dans une variable nommée idToken.
Elle enregistre le jeton d'ID dans un fichier temporaire nommé .workload_identity.jwt.
Elle crée un fichier de configuration des identifiants qui indique aux bibliothèques clientes de lire le jeton d'ID à partir de .workload_identity.jwt et de l'utiliser pour emprunter l'identité d'un compte de service.
Elle définit la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS de sorte qu'elle pointe vers le fichier de configuration des identifiants.

GitHub Actions

L'action google-github-actions/auth vous permet de générer automatiquement un fichier de configuration des identifiants lors de l'exécution du workflow. Les bibliothèques clientes et les outils tels que terraform peuvent ensuite utiliser ce fichier de configuration des identifiants pour obtenir automatiquement des identifiants Google.

Modifiez votre fichier YAML GitHub Actions et ajoutez les éléments suivants :

Autorisez la tâche à récupérer un jeton d'ID GitHub en ajoutant la configuration suivante :
```
permissions:
  id-token: write
  contents: read
```

Ajoutez une étape pour créer un fichier de configuration des identifiants :

- id: 'auth'
  name: 'Authenticate to Google Cloud'
  uses: 'google-github-actions/auth@v1'
  with:
    create_credentials_file: true
    workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
    service_account: 'SERVICE_ACCOUNT_EMAIL'

Remplacez les valeurs suivantes :

PROJECT_NUMBER : numéro de projet du projet contenant le pool d'identités de charge de travail
POOL_ID : ID du pool d'identités de charge de travail
PROVIDER_ID : ID du fournisseur du pool d'identités de charge de travail
SERVICE_ACCOUNT_EMAIL : remplacez par l'adresse e-mail du compte de service.

L'exemple suivant configure l'action GitHub :

jobs:
  build:
    # Allow the job to fetch a GitHub ID token
    permissions:
      id-token: write
      contents: read

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v1'
        with:
          create_credentials_file: true
          workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
          service_account: 'SERVICE_ACCOUNT_EMAIL'

Pour en savoir plus sur l'utilisation de l'action google-github-actions/auth, consultez la page Configurer la fédération d'identité de charge de travail.

GitLab SaaS

Modifiez votre fichier .gitlab-ci.yml et ajoutez les éléments suivants à la configuration du job :

job:
  variables:
    WORKLOAD_IDENTITY_PROJECT_NUMBER: PROJECT_NUMBER
    WORKLOAD_IDENTITY_POOL: POOL_ID
    WORKLOAD_IDENTITY_PROVIDER: PROVIDER_ID
    SERVICE_ACCOUNT: SERVICE_ACCOUNT_EMAIL
    GOOGLE_APPLICATION_CREDENTIALS: $CI_BUILDS_DIR/.workload_identity.wlconfig

  id_tokens:
    WORKLOAD_IDENTITY_TOKEN:
      aud: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

  script:
    - |-
      echo $WORKLOAD_IDENTITY_TOKEN > $CI_BUILDS_DIR/.workload_identity.jwt
      cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS
      {
        "type": "external_account",
        "audience": "//iam.googleapis.com/projects/$WORKLOAD_IDENTITY_PROJECT_NUMBER/locations/global/workloadIdentityPools/$WORKLOAD_IDENTITY_POOL/providers/$WORKLOAD_IDENTITY_PROVIDER",
        "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
        "token_url": "https://sts.googleapis.com/v1/token",
        "credential_source": {
          "file": "$CI_BUILDS_DIR/.workload_identity.jwt"
        },
        "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$SERVICE_ACCOUNT:generateAccessToken"
      }
      EOF

Remplacez les valeurs suivantes :

PROJECT_NUMBER : numéro du projet contenant le pool d'identités de charge de travail
POOL_ID : ID du pool d'identités de charge de travail
PROVIDER_ID : ID du fournisseur du pool d'identités de charge de travail
SERVICE_ACCOUNT_EMAIL : adresse e-mail du compte de service

La configuration effectue les opérations suivantes :

Indique à GitLab d'émettre un jeton d'ID et de le rendre disponible dans la variable d'environnement nommée WORKLOAD_IDENTITY_TOKEN. Le jeton d'ID utilise le fournisseur de votre pool d'identités de charge de travail comme audience.
Elle enregistre le jeton d'ID dans un fichier temporaire nommé .workload_identity.jwt.
Elle crée un fichier de configuration des identifiants qui indique aux bibliothèques clientes de lire le jeton d'ID à partir de .workload_identity.jwt et de l'utiliser pour emprunter l'identité d'un compte de service.
Elle définit la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS de sorte qu'elle pointe vers le fichier de configuration des identifiants.

Terraform Cloud

Configurez votre espace de travail Terraform Cloud de sorte qu'il utilise la fédération d'identité de charge de travail pour s'authentifier auprès de Google Cloud à l'aide de l'emprunt d'identité du compte de service :

Dans Terraform Cloud, ouvrez votre espace de travail et accédez à Variables.

Ajoutez les variables suivantes :

Catégorie de variable	Clé	Valeur
Variable d'environnement	`TFC_GCP_PROVIDER_AUTH`	`true`
Variable d'environnement	`TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL`	L'adresse e-mail du compte de service, par exemple `terraform@my-project-123.iam.gserviceaccount.com`.
Variable d'environnement	`TFC_GCP_PROJECT_NUMBER`	Numéro du projet contenant le pool d'identités de charge de travail
Variable d'environnement	`TFC_GCP_WORKLOAD_POOL_ID`	ID du pool d'identités de charge de travail
Variable d'environnement	`TFC_GCP_WORKLOAD_PROVIDER_ID`	ID du fournisseur du pool d'identités de charge de travail

Vous pouvez éventuellement ajouter des variables d'environnement supplémentaires pour permettre à Terrform Cloud d'utiliser différents comptes de service pour les phases plan et apply. Pour en savoir plus, consultez la page Variables d'environnement facultatives.

Dans la liste des variables, vérifiez que la Catégorie est définie sur env pour les cinq variables que vous avez ajoutées à l'étape précédente.
Vérifiez que votre configuration Terraform utilise la version 4.48.0 ou une version plus récente du fournisseur Google Cloud, et mettez-la à jour si nécessaire, comme suit :
```
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.48.0"
    }
  }
}
```
Envoyez les modifications vers le dépôt du code source.

Étapes suivantes

Apprenez-en plus sur la fédération d'identité de charge de travail.
Découvrez les bonnes pratiques d'utilisation de la fédération d'identité de charge de travail dans les pipelines de déploiement.
Découvrez comment vous pouvez gérer les pools d'identités de charge de travail et les fournisseurs.

Configurer la fédération d'identité de charge de travail avec des pipelines de déploiement

Avant de commencer

Configurer l'authentification

Console

gcloud

Python

Rôles requis

Préparer votre fournisseur d'identité externe

Azure DevOps

GitHub Actions

GitLab SaaS

Terraform Cloud

Configurer la fédération d'identité de charge de travail

Définir un mappage d'attributs

Azure DevOps

GitHub Actions

GitLab SaaS

Terraform Cloud

Définir une condition d'attribut

Azure DevOps

GitHub Actions

GitLab SaaS

Terraform Cloud

Créer le pool d'identité de charge de travail et le fournisseur

Console

Azure DevOps

GitHub Actions

GitLab SaaS

Terraform Cloud

gcloud

Azure DevOps

GitHub Actions

GitLab SaaS

Terraform Cloud

Mettre à jour la condition d'attribut sur un fournisseur d'identité de charge de travail

Console

gcloud

Authentifier un pipeline de déploiement

Autoriser votre charge de travail externe à accéder aux ressources Google Cloud

Accès direct aux ressources

Console

Par sujet

Par groupe

Par attribut

gcloud

Par sujet

Par groupe

Par attribut

Emprunter l'identité d'un compte de service

Console

gcloud

Par sujet

Par groupe

Par attribut

Configurer le pipeline de déploiement

Azure DevOps

GitHub Actions

GitLab SaaS

Terraform Cloud

Étapes suivantes