Gérer l'usurpation d'un compte de service

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette page explique comment autoriser les comptes principaux et les ressources à emprunter l'identité d'un compte de service Cloud IAM (Cloud Identity and Access Management), ou à agir en tant que ce compte. Elle explique également comment identifier les comptes principaux autorisés à emprunter l'identité d'un compte de service Cloud IAM donné.

Avant de commencer

Autoriser les comptes principaux à emprunter l'identité des comptes de service

Il existe plusieurs rôles prédéfinis qui permettent à un compte principal d'emprunter l'identité d'un compte de service :

  • Utilisateur du compte de service (roles/iam.serviceAccountUser) : ce rôle inclut l'autorisation iam.serviceAccounts.actAs, qui permet aux comptes principaux d'accéder indirectement à toutes les ressources auxquelles le compte de service peut accéder. Par exemple, si un compte principal dispose du rôle Utilisateur de compte de service sur un compte de service, et que ce compte de service dispose lui-même du rôle Administrateur Cloud SQL (roles/cloudsql.admin) sur le projet, le compte principal peut alors emprunter l'identité du compte de service pour créer une instance Cloud SQL.

    Ce rôle permet également aux comptes principaux d'associer un compte de service à une ressource, comme expliqué sur cette page.

    Ce rôle ne permet pas aux comptes principaux de créer des identifiants éphémères pour les comptes de service, ni d'utiliser l'option --impersonate-service-account pour Google Cloud CLI. Pour effectuer ces tâches, vous devez également disposer du rôle Créateur de jetons du compte de service.

  • Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator) : ce rôle permet aux comptes principaux d'emprunter l'identité des comptes de service pour effectuer les opérations suivantes :

    • Créer des jetons d'accès OAuth 2.0 que vous pouvez utiliser pour vous authentifier auprès des API Google
    • Créer des jetons d'identité OIDC (OpenID Connect)
    • Signer des jetons Web JSON (JWT) et des blobs binaires afin qu'ils puissent être utilisés pour l'authentification

    Pour en savoir plus, consultez la page Créer des identifiants de compte de service éphémères.

    Les autorisations du rôle incluent les suivantes :

    • iam.serviceAccounts.getAccessToken : vous permet de créer des jetons d'accès OAuth 2.0.
    • iam.serviceAccounts.getOpenIdToken : vous permet de créer des jetons d'identification OpenID Connect (OICD).
    • iam.serviceAccounts.implicitDelegation : permet aux comptes de service d'obtenir des jetons dans une chaîne de délégation.
    • iam.serviceAccounts.signBlob : vous permet de signer des blobs binaires.
    • iam.serviceAccounts.signJwt : vous permet de signer des jetons JWT.

  • Utilisateur Workload Identity (roles/iam.workloadIdentityUser) : ce rôle permet aux comptes principaux d'emprunter l'identité des comptes de service des charges de travail GKE.

    Les autorisations du rôle incluent les suivantes :

    • iam.serviceAccounts.getAccessToken : vous permet de créer des jetons d'accès OAuth 2.0.
    • iam.serviceAccounts.getOpenIdToken : vous permet de créer des jetons d'identification OpenID Connect (OICD).

Vous pouvez également attribuer un rôle prédéfini différent ou un rôle personnalisé, qui inclut les autorisations permettant d'emprunter l'identité des comptes de service.

Dans les sections suivantes, nous allons voir comment attribuer ces rôles sur des projets, des dossiers et des organisations, et comment les attribuer à des comptes de service individuels. Choisissez le niveau en fonction du niveau d'accès que vous souhaitez accorder :

Autoriser un compte principal à emprunter l'identité de plusieurs comptes de service

Pour autoriser un compte principal à emprunter l'identité de tous les comptes de service créés dans un projet, un dossier ou une organisation, accordez un rôle sur le projet, le dossier ou l'organisation.

Console

  1. Dans Google Cloud Console, accédez à la page IAM.

    Accéder à la page IAM

  2. Dans le sélecteur de projet en haut de la page, sélectionnez le projet, le dossier ou l'organisation pour lequel vous souhaitez attribuer le rôle.

  3. Cliquez sur Ajouter.

  4. Saisissez l'adresse e-mail de votre compte principal.

  5. Sélectionnez un rôle permettant au compte principal d'emprunter l'identité des comptes de service. Consultez la liste des rôles permettant d'emprunter l'identité des comptes de service.

  6. Cliquez sur Save (Enregistrer).

gcloud CLI

Pour accorder à un compte principal un rôle l'autorisant à emprunter l'identité d'un compte de service, modifiez la stratégie d'autorisation de votre projet, dossier ou organisation.

  1. Consultez la stratégie d'autorisation associée à la ressource :

    gcloud resource get-iam-policy resource-id \
    --format=json > policy.json

    Remplacez les valeurs suivantes :

    • resource : type de la ressource sur laquelle vous souhaitez définir la stratégie d'autorisation. Cette valeur doit correspondre à l'une des valeurs suivantes : projects, resource-manager folders ou organizations.
    • resource-id : ID de la ressource sur laquelle vous souhaitez définir la stratégie d'autorisation.

    La commande stocke la stratégie d'autorisation de la ressource dans un fichier policy.json.

    Si une stratégie d'autorisation est déjà définie sur la ressource, le fichier policy.json se présente comme suit :

    {
  "bindings": [
    {
      "members": [
        "user:hollis@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUqLaVeua8=",
  "version": 1
}

    S'il n'existe aucune stratégie d'autorisation sur la ressource, le fichier policy.json ne contient que la valeur etag par défaut.

    En l'absence de stratégie d'autorisation existante, créez-la manuellement en utilisant le code JSON des étapes suivantes comme modèle.

  2. Modifiez la stratégie d'autorisation pour attribuer les rôles appropriés à vos comptes principaux. Pour accorder un rôle, effectuez l'une des opérations suivantes :

    • Si aucune liaison pour le rôle n'existe, ajoutez un objet au tableau bindings qui indique le rôle que vous souhaitez attribuer et le compte principal auquel vous souhaitez l'accorder.
    • Si une liaison existe déjà pour le rôle, ajoutez le nouveau compte principal à la liste des comptes principaux existants. Si votre stratégie d'autorisation inclut des liaisons de rôle conditionnelles, assurez-vous également que la liaison contient les conditions appropriées avant d'ajouter le compte principal.

    Si le tableau bindings n'existe pas déjà, vous pouvez le créer.

    Exemple

    Pour accorder le rôle Utilisateur de compte de service (roles/iam.serviceAccountUser) à robin@example.com, modifiez l'exemple présenté à l'étape précédente comme suit :

    {
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/owner",
      "members": [
        "user:hollis@example.com"
      ]
    }
  ],
  "etag": "BwUqLaVeua8=",
  "version": 1
}

  3. Écrivez la stratégie d'autorisation mise à jour :

    gcloud resource set-iam-policy resource-id \
    policy-file

    Remplacez les valeurs suivantes :

    • resource : type de la ressource sur laquelle vous souhaitez définir la stratégie d'autorisation. Cette valeur doit correspondre à l'une des valeurs suivantes : projects, resource-manager folders ou organizations.
    • resource-id : ID de la ressource sur laquelle vous souhaitez définir la stratégie d'autorisation.
    • policy-file : chemin d'accès au fichier contenant la stratégie d'autorisation mise à jour.

    La commande imprime la stratégie d'autorisation mise à jour avec une valeur etag mise à jour.

REST

Pour attribuer un rôle à l'aide de l'API REST Resource Manager, vous devez lire la stratégie d'autorisation actuelle de votre projet, dossier ou organisation, la modifier pour attribuer les rôles souhaités, puis écrire la stratégie d'autorisation mise à jour.

Consultez la stratégie d'autorisation associée à la ressource.

La méthode getIamPolicy de l'API Resource Manager permet d'obtenir la stratégie d'autorisation d'un projet, d'un dossier ou d'une organisation.

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

  • API_VERSION : version de l'API à utiliser. Pour les projets et les organisations, utilisez v1. Pour les dossiers, utilisez v2.
  • RESOURCE_TYPE : type de ressource dont vous souhaitez gérer la stratégie. Utilisez la valeur projects, folders ou organizations.
  • RESOURCE_ID : ID du projet, de l'organisation ou du dossier Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project. Les ID de dossier et d'organisation sont numériques, tels que 123456789012.
  • POLICY_VERSION : version de la stratégie à renvoyer. Les requêtes doivent spécifier la version de stratégie la plus récente, qui est la version 3. Pour plus d'informations, consultez la section Spécifier une version de stratégie lors de l'obtention d'une stratégie.

Méthode HTTP et URL :

POST https://cloudresourcemanager.googleapis.com/API_VERSION/RESOURCE_TYPE/RESOURCE_ID:getIamPolicy

Corps JSON de la requête :

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

La réponse contient la stratégie d'autorisation de la ressource. Exemple : 

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/owner",
      "members": [
        "user:owner@example.com"
      ]
    }
  ]
}

En l'absence de stratégie d'autorisation existante, la réponse ne contient que la valeur etag par défaut. Si vous recevez cette réponse, ajoutez un champ version défini sur 3 et un champ bindings défini sur un tableau vide.

Modifiez la stratégie d'autorisation pour attribuer les rôles appropriés à vos comptes principaux.

Pour accorder un rôle, effectuez l'une des opérations suivantes :

  • Si aucune liaison pour le rôle n'existe, ajoutez un objet au tableau bindings qui indique le rôle que vous souhaitez attribuer et le compte principal auquel vous souhaitez l'accorder.
  • Si une liaison existe déjà pour le rôle, ajoutez le nouveau compte principal à la liste des comptes principaux existants.

Exemple :

Pour accorder le rôle Utilisateur de compte de service (roles/iam.serviceAccountUser) à robin@example.com, modifiez l'exemple présenté à l'étape précédente comme suit :

{
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/owner",
      "members": [
        "user:owner@example.com"
      ]
    }
  ]
}

Écrivez la stratégie d'autorisation mise à jour.

La méthode setIamPolicy de l'API Resource Manager définit la stratégie de la requête comme nouvelle stratégie d'autorisation pour le projet, le dossier ou l'organisation.

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

  • API_VERSION : version de l'API à utiliser. Pour les projets et les organisations, utilisez v1. Pour les dossiers, utilisez v2.
  • RESOURCE_TYPE : type de ressource dont vous souhaitez gérer la stratégie. Utilisez la valeur projects, folders ou organizations.
  • RESOURCE_ID : ID du projet, de l'organisation ou du dossier Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project. Les ID de dossier et d'organisation sont numériques, tels que 123456789012.

  • POLICY : représentation JSON de la stratégie que vous souhaitez définir. Pour en savoir plus sur le format d'une stratégie, consultez la documentation de référence sur les stratégies.

    Par exemple, pour définir la stratégie d'autorisation présentée à l'étape précédente, remplacez POLICY par ce qui suit :

    {
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/owner",
      "members": [
        "user:owner@example.com"
      ]
    }
  ]
}

Méthode HTTP et URL :

POST https://iam.googleapis.com/API_VERSION/RESOURCE_TYPE/RESOURCE_ID:setIamPolicy

Corps JSON de la requête :

{
  "policy": POLICY
}

Pour envoyer votre requête, développez l'une des options suivantes :

La réponse contient la stratégie d'autorisation mise à jour.

Autoriser un compte principal à emprunter l'identité d'un seul compte de service

Pour permettre à un compte principal d'emprunter l'identité d'un seul compte de service, attribuez un rôle sur le compte de service :

Console

  1. Dans la console Google Cloud, accédez à la page Comptes de service.

    Accéder à la page "Comptes de service"

  2. Sélectionnez un projet.

  3. Cliquez sur l'adresse e-mail du compte de service dont vous souhaitez que le compte principal puisse emprunter l'identité.

  4. Cliquez sur l'onglet Autorisations.

  5. Sous Comptes principaux avec accès à ce compte de service, cliquez sur  Accorder l'accès.

  6. Saisissez l'adresse e-mail de votre compte principal.

  7. Sélectionnez un rôle autorisant le compte principal à emprunter l'identité des comptes de service. Consultez la liste des rôles permettant d'emprunter l'identité des comptes de service.

  8. Cliquez sur Enregistrer pour appliquer le rôle au compte principal.

Pour attribuer des rôles sur plusieurs comptes de service, répétez ces étapes pour chaque compte de service.

gcloud CLI

Pour accorder à un compte principal un rôle l'autorisant à emprunter l'identité d'un compte de service, modifiez la stratégie d'autorisation de votre compte de service.

  1. Utilisez la commande service-accounts get-iam-policy pour lire la stratégie d'autorisation actuelle :

    gcloud iam service-accounts get-iam-policy sa-id \
    --format=json > policy.json

    Remplacez les valeurs suivantes :

    • sa-id : ID de votre compte de service. Il peut s'agir de l'adresse e-mail du compte de service au format sa-name@project-id.iam.gserviceaccount.com ou de l'ID numérique unique du compte de service.

    La commande stocke la stratégie d'autorisation du compte de service dans un fichier policy.json.

    Si une stratégie d'autorisation est déjà définie sur le compte de service, le fichier policy.json se présente comme suit :

    {
  "bindings": [
    {
      "members": [
        "user:hollis@example.com"
      ],
      "role": "roles/iam.serviceAccountAdmin"
    }
  ],
  "etag": "BwUqLaVeua8=",
  "version": 1
}

    Si aucune stratégie d'autorisation n'est définie sur le compte de service, le fichier policy.json ne contient que le etag par défaut.

    En l'absence de stratégie d'autorisation existante, créez-la manuellement en utilisant le code JSON des étapes suivantes comme modèle.

  2. Dans un éditeur de texte, modifiez le tableau de liaisons dans le fichier policy.json afin d'attribuer les rôles appropriés aux comptes principaux. Pour accorder un rôle, effectuez l'une des opérations suivantes :

    • Si aucune liaison pour le rôle n'existe, ajoutez un objet au tableau bindings qui indique le rôle que vous souhaitez attribuer et le compte principal auquel vous souhaitez l'accorder.
    • Si une liaison existe déjà pour le rôle, ajoutez le nouveau compte principal à la liste des comptes principaux existants. Si votre stratégie d'autorisation inclut des liaisons de rôle conditionnelles, assurez-vous également que la liaison contient les conditions appropriées avant d'ajouter le compte principal.

    Si le tableau bindings n'existe pas déjà, vous pouvez le créer.

    Exemple

    Pour accorder le rôle Utilisateur de compte de service (roles/iam.serviceAccountUser) à robin@example.com, modifiez l'exemple présenté à l'étape précédente comme suit :

    {
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountAdmin",
      "members": [
        "user:hollis@example.com"
      ]
    }
  ],
  "etag": "BwUqLaVeua8=",
  "version": 1
}

  3. Exécutez la commande service-accounts set-iam-policy pour écrire la stratégie d'autorisation mise à jour :

    gcloud iam service-accounts set-iam-policy sa-id \
    policy-file

    Remplacez les valeurs suivantes :

    • sa-id : ID de votre compte de service. Il peut s'agir de l'adresse e-mail du compte de service au format sa-name@project-id.iam.gserviceaccount.com ou de l'ID numérique unique du compte de service.

    • policy-file : chemin d'accès au fichier contenant la stratégie d'autorisation mise à jour.

    La commande imprime la stratégie d'autorisation mise à jour avec une valeur etag mise à jour.

REST

Pour attribuer un rôle à l'aide de l'API REST IAM, vous devez lire la stratégie d'autorisation actuelle du compte de service, la modifier pour attribuer les rôles souhaités, puis écrire la stratégie mise à jour.

Lisez la stratégie d'autorisation du compte de service.

La méthode serviceAccounts.getIamPolicy permet d'obtenir la stratégie d'autorisation d'un compte de service.

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

  • PROJECT_ID : ID de votre projet Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project.

  • SA_ID : ID de votre compte de service. Il peut s'agir de l'adresse e-mail du compte de service au format SA_NAME@PROJECT_ID.iam.gserviceaccount.com ou de l'ID numérique unique du compte de service.

  • POLICY_VERSION : version de la stratégie à renvoyer. Les requêtes doivent spécifier la version de stratégie la plus récente, qui est la version 3. Pour plus d'informations, consultez la section Spécifier une version de stratégie lors de l'obtention d'une stratégie.

Méthode HTTP et URL :

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:getIamPolicy

Corps JSON de la requête :

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

La réponse contient la stratégie d'autorisation du compte de service. Exemple : 

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

En l'absence de stratégie d'autorisation existante, la réponse ne contient que la valeur etag par défaut. Si vous recevez cette réponse, ajoutez un champ version défini sur 3 et un champ bindings défini sur un tableau vide.

Modifiez la stratégie d'autorisation pour attribuer les rôles appropriés à vos comptes principaux.

Dans un éditeur de texte, modifiez le tableau de liaisons du corps de la réponse pour attribuer les rôles appropriés aux comptes principaux. Pour accorder un rôle, effectuez l'une des opérations suivantes :

  • Si aucune liaison pour le rôle n'existe, ajoutez un objet au tableau bindings qui indique le rôle que vous souhaitez attribuer et le compte principal auquel vous souhaitez l'accorder.
  • Si une liaison existe déjà pour le rôle, ajoutez le nouveau compte principal à la liste des comptes principaux existants.

Exemple :

Pour accorder le rôle Utilisateur de compte de service (roles/iam.serviceAccountUser) à robin@example.com, modifiez l'exemple présenté à l'étape précédente comme suit :

{
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Écrivez la stratégie d'autorisation mise à jour.

La méthode serviceAccounts.setIamPolicy définit une stratégie d'autorisation mise à jour pour le compte de service.

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

  • PROJECT_ID : ID de votre projet Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project.

  • SA_ID : ID de votre compte de service. Il peut s'agir de l'adresse e-mail du compte de service au format SA_NAME@PROJECT_ID.iam.gserviceaccount.com ou de l'ID numérique unique du compte de service.

  • POLICY : représentation JSON de la stratégie que vous souhaitez définir. Pour en savoir plus sur le format d'une stratégie, consultez la documentation de référence sur les stratégies.

    Par exemple, pour définir la stratégie d'autorisation présentée à l'étape précédente, remplacez policy par ce qui suit :

    {
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Méthode HTTP et URL :

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:setIamPolicy

Corps JSON de la requête :

{
  "policy": POLICY
}

Pour envoyer votre requête, développez l'une des options suivantes :

La réponse contient la stratégie d'autorisation mise à jour.

Répertorier les comptes principaux pouvant accéder à un compte de service

Utilisez la console Google Cloud pour afficher tous les comptes principaux ayant accès à un compte de service, soit en raison des rôles attribués à celui-ci, soit en raison des rôles attribués au projet, au dossier ou à l'organisation :

  1. Dans la console Google Cloud, accédez à la page Comptes de service.

    Accéder à la page "Comptes de service"

  2. Sélectionnez un projet.

  3. Cliquez sur l'adresse e-mail du compte de service dont vous souhaitez que le compte principal puisse emprunter l'identité.

  4. Cliquez sur l'onglet Autorisations. La section Comptes principaux ayant accès à ce compte de service répertorie les comptes principaux pouvant accéder au compte de service.

Associer un compte de service à une ressource

Pour certaines ressources Google Cloud, vous pouvez spécifier un compte de service géré par l'utilisateur que la ressource utilise comme identité par défaut. Ce processus est appelé liaison du compte de service à la ressource, ou association du compte de service à la ressource.

Lorsqu'une ressource doit accéder à d'autres services et ressources Google Cloud, elle usurpe l'identité du compte de service qui lui est associé. Par exemple, si vous associez un compte de service à une instance Compute Engine et que les applications de l'instance utilisent une bibliothèque cliente pour appeler les API Google Cloud, ces applications usurpent automatiquement l'identité du compte de service associé.

Dans la plupart des cas, vous devez associer un compte de service à une ressource lorsque vous créez cette ressource. Une fois la ressource créée, vous ne pouvez pas modifier le compte de service qui lui est associé. Les instances Compute Engine font exception à cette règle : si nécessaire, vous pouvez modifier le compte de service associé à une instance.

Avant d'associer un compte de service à une ressource, vous devez configurer le compte de service. Ce processus diffère selon que le compte de service et la ressource se trouvent dans le même projet ou dans des projets différents. Après avoir configuré le compte de service, vous pouvez créer la ressource et lui associer le compte de service.

Configurer une ressource dans le même projet

Avant d'associer un compte de service à une autre ressource du même projet, accordez des rôles au compte de service afin qu'il puisse accéder aux ressources appropriées, de la même manière que vous attribueriez des rôles aux autres comptes principaux.

Configurer une ressource dans un autre projet

Dans certains cas, vous devrez peut-être associer un compte de service à une ressource située dans un autre projet. Par exemple, si vous créez tous vos comptes de service dans un seul projet, vous devrez peut-être en associer un à une nouvelle ressource d'un autre projet.

Avant d'associer un compte de service à une ressource d'un autre projet, procédez comme suit :

  1. Dans le projet où se trouve le compte de service, suivez les étapes décrites sur cette page pour activer l'usurpation d'identité pour tous les projets.
  2. Identifiez le projet dans lequel vous allez créer la ressource.

  3. Identifiez le type de ressource auquel vous allez associer le compte de service, ainsi que le service qui possède ce type de ressource.

    Par exemple, si vous créez un abonnement Pub/Sub, Pub/Sub est le service qui possède la ressource.

  4. Recherchez l'adresse e-mail de l'agent de service du service.

    Les différents services utilisent des agents de service différents. Pour en savoir plus, consultez la section Agents de service.

  5. Attribuez le rôle de créateur de jetons de compte de service (roles/iam.serviceAccountTokenCreator) aux agents de service :

    Console

    1. Dans Google Cloud Console, accédez à la page Comptes de service.

      Accéder à la page "Comptes de service"

    2. Sélectionnez le projet qui possède le compte de service que vous allez associer à une ressource.

    3. Recherchez le compte de service que vous allez associer à une ressource, puis cochez la case correspondante.

    4. Dans le volet Autorisations, cliquez sur Ajouter un compte principal.

    5. Dans le champ Nouveaux comptes principaux, saisissez l'adresse e-mail de l'agent de service.

    6. Dans la liste déroulante Sélectionner un rôle, saisissez Service Account Token Creator puis cliquez sur le rôle.

    7. Cliquez sur Enregistrer pour enregistrer les modifications.

    8. Facultatif : si vous devez attribuer le rôle à un autre agent de service, répétez les étapes précédentes.

    gcloud CLI

    Exécutez la commande gcloud iam service-accounts add-iam-policy-binding :

    gcloud iam service-accounts add-iam-policy-binding \
    user-sa-name@project-id.iam.gserviceaccount.com \
    --member=serviceAccount:service-agent-email \
    --role=roles/iam.serviceAccountTokenCreator

    Remplacez les valeurs suivantes :

    • user-sa-name : nom du compte de service géré par l'utilisateur que vous associez à une ressource.
    • project-id : ID du projet dans lequel se trouve le compte de service géré par l'utilisateur.
    • service-agent-email : adresse e-mail associée au compte de service.

    La commande affiche la stratégie d'autorisation mise à jour du compte de service géré par l'utilisateur.

    Facultatif : si vous devez attribuer le rôle à un autre agent de service, exécutez à nouveau la commande.

    REST

    Pour accorder ce rôle, utilisez le modèle lecture-modification-écriture afin de mettre à jour la stratégie d'autorisation de votre compte de service géré par l'utilisateur.

    Tout d'abord, lisez la stratégie d'autorisation du compte de service géré par l'utilisateur :

    La méthode projects.serviceAccounts.getIamPolicy renvoie la stratégie d'autorisation pour le compte de service.

    Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

    • PROJECT_ID : ID de votre projet Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project.
    • USER_SA_NAME : nom du compte de service géré par l'utilisateur que vous associez à une ressource.

    Méthode HTTP et URL :

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

    Corps JSON de la requête :

    {
  "requestedPolicyVersion": 3
}

    Pour envoyer votre requête, développez l'une des options suivantes :

    Vous devriez recevoir une réponse JSON de ce type :

    {
  "version": 1,
  "etag": "BwWl3KCTUMY=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"
      ]
    }
  ]
}

    Ensuite, modifiez la stratégie d'autorisation pour accorder le rôle de créateur de jetons du compte de service à l'agent de service. Remplacez SERVICE_AGENT_EMAIL par l'adresse e-mail du compte de service.

    {
  "version": 1,
  "etag": "BwWl3KCTUMY=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SERVICE_AGENT_EMAIL"
      ]
    },
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"
      ]
    }
  ]
}

    Enfin, écrivez la stratégie d'autorisation mise à jour :

    La méthode projects.serviceAccounts.setIamPolicy met à jour la stratégie d'autorisation de votre compte de service.

    Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

    • PROJECT_ID : ID de votre projet Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project.
    • USER_SA_NAME : nom du compte de service géré par l'utilisateur que vous associez à une ressource.
    • SERVICE_AGENT_EMAIL : adresse e-mail de l'agent de service qui créera des jetons d'accès pour votre compte de service géré par l'utilisateur.

    Méthode HTTP et URL :

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy

    Corps JSON de la requête :

    {
  "policy": {
    "version": 1,
    "etag": "BwWl3KCTUMY=",
    "bindings": [
      {
        "role": "roles/iam.serviceAccountTokenCreator",
        "members": [
          "serviceAccount:SERVICE_AGENT_EMAIL"
        ]
      },
      {
        "role": "roles/iam.serviceAccountUser",
        "members": [
          "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"
        ]
      }
    ]
  }
}

    Pour envoyer votre requête, développez l'une des options suivantes :

    Vous devriez recevoir une réponse JSON de ce type :

    {
  "version": 1,
  "etag": "BwWo331TkHE=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SERVICE_AGENT_EMAIL"
      ]
    },
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"
      ]
    }
  ]
}

Associer le compte de service à la nouvelle ressource

Après avoir configuré le compte de service géré par l'utilisateur, vous pouvez créer une ressource et lui associer le compte de service. Assurez-vous de créer la ressource dans le projet approprié.

Consultez les instructions concernant le type de ressource que vous souhaitez créer :

Associer un compte de service lors de la création d'une ressource
AI Platform Prediction Versions de modèle
AI Platform Training Tâches
Environnement standard App Engine Versions d'application
Environnement flexible App Engine Versions d'application
Cloud Composer Environnements
Cloud Functions Fonction Cloud
Cloud Life Sciences Pipelines
Cloud Run Services
Cloud Scheduler Tâches
Cloud Source Repositories
Compute Engine
Dataflow Tâches
Datalab Instances
Dataproc Clusters
Google Kubernetes Engine
Notebooks Instances de notebook
Pub/Sub Abonnements
Vertex AI
Workflows Workflows

Après avoir créé la ressource et associé le compte de service à celle-ci, vous pouvez attribuer des rôles au compte de service afin qu'il puisse accéder aux ressources appropriées. Ce processus revient à attribuer un rôle à un autre compte principal.

Pour savoir comment attribuer des rôles, consultez la section Accorder, modifier et révoquer les accès aux ressources.

Interpréter les journaux d'audit

Les journaux d'audit Cloud vous aident à répondre à des questions telles que "Qui a fait quoi, où et quand ?" pour vos ressources Google Cloud.

Lorsque vous utilisez des identifiants éphémères pour usurper l'identité d'un compte de service, la plupart des services Google Cloud créent des entrées de journal indiquant les identités suivantes :

  • Compte de service dont l'identité est empruntée par les identifiants éphémères
  • Identité ayant créé les identifiants éphémères

Vous pouvez utiliser ces entrées de journal pour identifier le compte principal qui a créé les identifiants éphémères, ainsi que le compte de service dont l'identité a été empruntée.

Pour obtenir des exemples d'entrées de journal d'audit indiquant l'usurpation d'identité d'un compte de service, consultez la section Usurper l'identité d'un compte de service pour accéder à Google Cloud.

Activer l'usurpation d'identité d'un compte de service dans les projets

Par défaut, vous ne pouvez pas créer un compte de service dans un projet et l'associer à une ressource d'un autre projet. Si vous souhaitez conserver tous vos comptes de service dans un seul projet, vous devez mettre à jour la règle d'administration pour ce projet.

Dans la règle d'administration du projet où se trouvent vos comptes de service, vérifiez les contraintes booléennes suivantes :

  • Assurez-vous que la contrainte booléenne iam.disableCrossProjectServiceAccountUsage n'est pas appliquée pour le projet.

    Cette contrainte booléenne détermine si vous pouvez associer un compte de service à une ressource d'un autre projet. La contrainte est appliquée par défaut.

    Si cette contrainte n'est pas appliquée, IAM ajoute un privilège de projet qui empêche la suppression du projet. Ce privilège a l'origine iam.googleapis.com/cross-project-service-accounts. Nous vous déconseillons vivement de supprimer ce privilège.

  • Recommandé : assurez-vous que la contrainte booléenne iam.restrictCrossProjectServiceAccountLienRemoval est appliquée pour le projet.

    Cette contrainte booléenne garantit que les comptes principaux ne peuvent supprimer le privilège du projet que s'ils disposent de l'autorisation resourcemanager.projects.updateLiens au niveau de l'organisation. Si cette contrainte n'est pas appliquée, les comptes principaux peuvent supprimer le privilège du projet s'ils disposent de cette autorisation au niveau du projet.

Pour savoir comment afficher ou modifier une contrainte booléenne dans une règle d'administration, consultez la section Définir une contrainte booléenne.

Désactiver l'usurpation d'identité d'un compte de service dans les projets

Si vous avez déjà activé l'usurpation d'identité pour les projets de service, nous vous déconseillons vivement de désactiver cette fonctionnalité, en particulier dans les environnements de production.

Plus précisément, dans le projet où se trouvent vos comptes de service, vous ne devez effectuer aucune des modifications suivantes :

  • Ne modifiez pas la règle d'administration du projet pour appliquer la contrainte booléenne iam.disableCrossProjectServiceAccountUsage.
  • Ne modifiez pas la règle d'administration du projet pour désactiver l'application de la contrainte booléenne iam.restrictCrossProjectServiceAccountLienRemoval.
  • Ne supprimez pas le privilège de projet avec l'origine iam.googleapis.com/cross-project-service-accounts, car il vous empêche de supprimer le projet.
  • Ne supprimez pas le projet.

Si vous êtes prêt à accepter le risque de désactiver cette fonctionnalité, vous pouvez tout de même réduire les risques en désactivant les comptes de service que vous utilisez dans les projets, puis en surveillant votre environnement Google Cloud pour détecter d'éventuels problèmes. Si vous rencontrez des problèmes, vous pouvez réactiver les comptes de service. Si vous ne constatez aucun problème, vous ne disposez peut-être pas de ressources Google Cloud qui dépendent d'un compte de service situé dans un autre projet.

Étape suivante