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

Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :

Console

Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud, vous n'avez pas besoin de configurer l'authentification.

gcloud

Vous pouvez utiliser les exemples gcloud CLI de cette page dans l'un des environnements de développement suivants :

  • Cloud Shell : pour utiliser un terminal en ligne avec gcloud CLI déjà configuré, activez Cloud Shell.

    En bas de cette page, une session Cloud Shell démarre et affiche une invite de ligne de commande. L'initialisation de la session peut prendre quelques secondes.

  • Shell local : pour utiliser gcloud CLI dans un environnement de développement local, installez et initialisez gcloud CLI.

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.

  1. Installez Google Cloud CLI.
  2. Pour initialiser gcloudCLI, exécutez la commande suivante :

    gcloud init
  3. Créez des identifiants d'authentification locaux pour votre compte Google :

    gcloud auth application-default login

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 :

  1. Dans Azure DevOps, ouvrez votre projet et accédez à Paramètres du projet.
  2. Accédez à Pipelines > Connexions de service.
  3. Cliquez sur Créer une connexion de service.
  4. Sélectionnez Azure Resource Manager.
  5. Cliquez sur Suivant.
  6. Sélectionnez Fédération d'identité de charge de travail (automatique).
  7. Cliquez sur Suivant.
  8. 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.

  9. 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 :

  1. Cliquez sur la connexion de service que vous venez de créer.
  2. Cliquez sur Gérer le compte principal de service.
  3. Accédez à Certificat et secrets > Identifiants fédérés.
  4. Cliquez sur l'identifiant fédéré.
  5. 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 :

  1. Sur le portail Azure, ouvrez l'abonnement que vous avez sélectionné comme champ d'application.
  2. Accédez à Contrôle des accès (IAM) > Attributions de rôles.
  3. 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 :

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

    Go to project selector

  2. Il est préférable d'utiliser un projet dédié pour gérer les pools et les fournisseurs d'identités de charge de travail.
  3. Vérifiez que la facturation est activée pour votre projet Google Cloud.

  4. Activer les API IAM, Resource Manager, Service Account Credentials, and Security Token Service.

    Activer les API

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

  1. 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

  2. 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.
  3. Cliquez sur Continuer.

  4. 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
  5. Cliquez sur Continuer.

  6. Sous Configurer les attributs de fournisseur, ajoutez les mappages d'attributs que vous avez identifiés précédemment.

  7. Sous Conditions d'attribut, saisissez la condition d'attribut que vous avez identifiée précédemment.

  8. Cliquez sur Enregistrer pour créer le pool d'identités de charge de travail et le fournisseur.

gcloud

  1. 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.
  2. 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 :

    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 :

    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 :

    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 :

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

  1. 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

  2. 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.

  3. Recherchez le fournisseur du pool d'identités de charge de travail que vous souhaitez modifier, puis cliquez sur Modifier.

  4. Dans Conditions d'attribut, saisissez la condition d'attribut que vous avez identifiée précédemment.

  5. 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 :

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.

  1. Dans la console Google Cloud, accédez à la page Buckets Cloud Storage.

    Accéder à la page "Buckets"

  2. Dans la liste des buckets, cliquez sur le nom du bucket pour lequel vous souhaitez attribuer le rôle.

  3. Sélectionnez l'onglet Autorisations en haut de la page.

  4. Cliquez sur le bouton  Accorder l'accès.

    La boîte de dialogue Ajouter des entités principales s'affiche.

  5. 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
  6. 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.

  7. 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 :

  1. 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\)
    
  2. 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.

Emprunter l'identité d'un compte de service

  1. Pour créer un compte de service pour la charge de travail externe, procédez comme suit :

    1. Activer les API IAM, Security Token Service, and Service Account Credentials.

      Activer les API

    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.

  2. 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. Activer les API IAM, Security Token Service, and Service Account Credentials.

        Activer les API

      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

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 :

  1. 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.
  2. Elle enregistre le jeton d'ID dans un fichier temporaire nommé .workload_identity.jwt.
  3. 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.
  4. 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 :

  1. 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.
  2. Elle enregistre le jeton d'ID dans un fichier temporaire nommé .workload_identity.jwt.
  3. 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.
  4. 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 :

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

  2. 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.

  3. 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.

  4. 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"
        }
      }
    }
    
  5. Envoyez les modifications vers le dépôt du code source.

Étapes suivantes