Créer des identifiants de compte de service éphémères

Cette page explique comment créer des identifiants éphémères pour les comptes de service afin qu'ils empruntent leurs identités.

Les comptes de service peuvent utiliser des identifiants éphémères pour authentifier les appels aux API Google Cloud et à des API autres que Google. Les identifiants éphémères ont une durée de vie limitée, de quelques heures ou moins. Les identifiants de compte de service éphémères sont utiles pour les scénarios dans lesquels vous devez accorder un accès limité aux ressources des comptes de service de confiance. Ils présentent également moins de risques que les identifiants longue durée, tels que les clés de compte de service.

Les types d'identifiants pris en charge sont les jetons d'accès OAuth 2.0, les jetons d'identification OpenID Connect, les jetons JSON Web (JWT) autosignés et les objets binaires autosignés (blobs). Les types d'identifiants les plus couramment utilisés sont les jetons d'accès OAuth 2.0 et les jetons d'identification OpenID Connect (OIDC). Voici quelques exemples de scénarios :

  • Jeton d'accès OAuth 2.0 : un jeton d'accès OAuth 2.0 est utile pour authentifier l'accès depuis un compte de service vers des API Google Cloud. Prenons l'exemple suivant : pour obtenir des autorisations avec privilèges élevés sur un projet, un administrateur de service peut emprunter un compte de service pour appeler des API Google Cloud en créant un jeton d'accès OAuth 2.0. La durée de vie du jeton est courte, de sorte que les autorisations avec privilèges élevés sont temporaires. L'utilisation de jetons de courte durée vous aide à mettre en œuvre le principe du moindre privilège pour l'ensemble de vos identités et ressources. Cela peut également être utile en cas d'urgence dans un environnement de production lorsqu'un administrateur de service a besoin d'une autorisation avec privilèges élevés à court terme pour le débogage.

  • Jeton d'identification OIDC : un jeton d'identification OIDC est utile pour authentifier l'identité d'un compte de service auprès de services qui acceptent OpenID Connect. Prenons l'exemple suivant : en créant un jeton d'identification OIDC appartenant à un compte de service, un service exécuté sur Google Cloud peut s'authentifier auprès d'un autre service déployé sur un fournisseur de cloud tiers tel qu'une tâche de pipeline de données. Si le service cible est configuré avec OIDC, l'authentification réussira.

Avant de commencer

  • Enable the IAM and Service Account Credentials APIs.

    Enable the APIs

  • Consultez la documentation relative aux comptes de service IAM.

  • Si vous ne l'avez pas déjà fait, activez la facturation et l'API IAM en suivant les étapes du guide de démarrage rapide.

Créer un compte de service

Pour commencer, créez un compte de service.

Fournir les autorisations requises

Deux flux distincts permettent à l'auteur d'un appel de créer des identifiants éphémères pour un compte de service. Chacun de ces flux requiert les autorisations appropriées :

  • Requête directe : l'auteur de l'appel est authentifié en tant que compte Google ou compte de service, et envoie directement une requête pour créer des identifiants éphémères. Deux identités sont impliquées dans ce flux : l'auteur de l'appel et le compte de service pour lequel l'identifiant est créé.

  • Requête déléguée : de même que pour le flux de requête directe, l'auteur de l'appel est authentifié en tant que compte Google ou compte de service, mais la requête est déléguée à un ou plusieurs comptes de service formant une chaîne de délégation. Dans ce flux, plusieurs comptes de service agissent en tant qu'intermédiaires entre l'auteur de l'appel initial et le compte de service pour lequel l'identifiant est créé. Chaque compte de service de la chaîne de délégation doit disposer des autorisations requises pour transmettre la requête.

    Ce flux est utile pour les situations où un projet contient différents niveaux de comptes de service à privilèges restreints, dont chacun a été configuré pour exécuter une fonction spécifique ou limitée sur certaines ressources. Par exemple, un compte de service ne dispose que d'autorisations sur les ressources Cloud Storage, un autre, que des autorisations limitées aux ressources Compute Engine, etc. Une requête déléguée auprès de plusieurs comptes de service ne peut aboutir que si chacun de ces comptes de service est répertorié dans la chaîne de délégation.

Autorisations de requête directe

Comme décrit dans la section Accorder les autorisations requises sur cette page, une demande directe n'implique que deux identités : l'auteur de l'appel et le compte de service pour lequel l'identifiant est créé. Dans ce flux, il convient de prendre en considération les identités suivantes :

  • Le compte de service 1 (SA_1) correspond à l'auteur de l'appel qui émet une requête de création d'identifiants éphémères.
  • Le compte de service 2 (SA_2) est un compte doté de privilèges limités pour lequel l'identifiant est créé.

Pour accorder à SA_1 les autorisations de créer des identifiants éphémères, attribuez-lui le rôle de créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator) sur SA_2. Voici un exemple de compte de service SA_2 traité comme une ressource : lorsque vous attribuez le rôle sur SA_2, vous mettez à jour sa stratégie d'autorisation de la même manière que vous le feriez pour toute autre ressource.

Les étapes suivantes font appel à l'API REST pour attribuer le rôle. Cependant, vous pouvez également utiliser Cloud Console ou la CLI gcloud.

API

Commencez par lire la stratégie d'autorisation pour SA_2 :

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_2 : nom du compte de service 2.
  • 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_2@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

Corps JSON de la requête :

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

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": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Si vous n'avez pas attribué de rôle au compte de service, la réponse ne contient qu'une valeur etag. Incluez cette valeur etag à l'étape suivante.

Ensuite, modifiez la stratégie d'autorisation pour accorder à SA_1 le rôle de créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator).

Par exemple, pour modifier l'exemple de réponse de l'étape précédente, ajoutez ce qui suit :

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

Enfin, é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_2 : nom du compte de service 2.

  • 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": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Méthode HTTP et URL :

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com: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.

Autorisations de requête déléguée

Comme décrit dans la section Accorder les autorisations requises sur cette page, une requête déléguée implique plus de deux identités : l'auteur de l'appel, un ou plusieurs comptes de service dans une chaîne de délégation, et enfin le service compte. Dans ce flux, il convient de prendre en considération les identités suivantes :

  • Le compte de service 1 (SA_1) correspond à l'auteur de l'appel qui émet une requête de création d'identifiants éphémères.
  • Le compte de service 2 (SA_2) est un compte de service intermédiaire qui déléguera la requête initiale à SA_3.
  • Le compte de service 3 (SA_3) est un compte à privilèges limités pour lequel l'identifiant est créé.

Pour autoriser la délégation, chaque compte doit accorder le rôle de créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator) au compte de la chaîne précédent.

Dans cet exemple, SA_1 doit disposer du rôle de créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator) sur SA_2. Voici un exemple de compte de service SA_2 traité comme une ressource : lorsque vous accordez le rôle sur SA_2, vous mettez à jour sa stratégie d'autorisation de la même manière que vous le feriez pour toute autre ressource.

Cet exemple de flux ne fait intervenir qu'un seul compte de service intermédiaire. Pour déléguer l'accès à plusieurs comptes de service, vous devez également affecter ce rôle à tous les autres comptes de service de la chaîne.

Ensuite, SA_2 doit également disposer du rôle de créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator) sur SA_3. Cela permet à SA_2 de créer des identifiants éphémères pour SA_3.

Les étapes suivantes font appel à l'API REST pour attribuer les rôles. Cependant, vous pouvez également utiliser Cloud Console ou la CLI gcloud.

API

Tout d'abord, obtenez la stratégie d'autorisation pour SA_2 (le compte de service intermédiaire) :

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_2 : nom du compte de service 2.
  • 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_2@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

Corps JSON de la requête :

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

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": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Si vous n'avez pas attribué de rôle au compte de service, la réponse ne contient qu'une valeur etag. Incluez cette valeur etag à l'étape suivante.

Ensuite, modifiez la stratégie d'autorisation pour accorder à SA_1 le rôle de créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator).

Par exemple, pour modifier l'exemple de réponse de l'étape précédente, ajoutez ce qui suit :

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

Enfin, rédigez la stratégie d'autorisation mise à jour pour SA_2 :

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_2 : nom du compte de service 2.

  • 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": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Méthode HTTP et URL :

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com: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.

Maintenant, obtenez la stratégie d'autorisation pour SA_3 (le compte de service pour lequel l'identifiant est créé) :

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_3 : nom du compte de service 3.
  • 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_3@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

Corps JSON de la requête :

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

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": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Si vous n'avez pas attribué de rôle au compte de service, la réponse ne contient qu'une valeur etag. Incluez cette valeur etag à l'étape suivante.

Ensuite, modifiez la stratégie d'autorisation pour accorder à SA_2 le rôle de créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator).

Par exemple, pour modifier l'exemple de réponse de l'étape précédente, ajoutez ce qui suit :

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

Enfin, é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_3 : nom du compte de service 3.

  • 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": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Méthode HTTP et URL :

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com: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.

Demander des identifiants éphémères

Une fois que vous avez attribué les rôles appropriés à chaque identité, vous pouvez demander des identifiants éphémères pour le compte de service souhaité. Les types d'identifiants compatibles sont les suivants :

Pour comprendre comment spécifier une chaîne de délégation pour ces requêtes, consultez la section Spécifier une chaîne de délégation sur cette page.

Générer un jeton d'accès OAuth 2.0

Par défaut, les jetons d'accès OAuth 2.0 sont valides pendant une durée maximale d'une heure (3 600 secondes). Toutefois, vous pouvez étendre la durée de vie maximale de ces jetons à 12 heures (43 200 secondes). Pour ce faire, identifiez les comptes de service qui ont besoin de jetons à durée de vie prolongée, puis ajoutez-les à une règle d'administration qui comprend la contrainte de liste constraints/iam.allowServiceAccountCredentialLifetimeExtension. Vous pouvez ensuite spécifier une durée de vie maximale de 43 200 secondes lorsque vous créez un jeton pour ces comptes de service.

Pour générer un jeton d'accès OAuth 2.0 pour un compte de service, procédez comme suit :

API

La méthode serviceAccounts.generateAccessToken de l'API Service Account Credentials génère un jeton d'accès OAuth 2.0 pour un compte de service.

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

  • SA_NAME : nom du compte de service pour lequel vous souhaitez créer un jeton.
  • PROJECT_ID : ID de votre projet Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project.
  • DELEGATES : si vous utilisez un flux de requête déléguée, consultez la section Spécifier une chaîne de délégation de cette page. Dans le cas d'un flux de requête directe (sans délégation), vous devez omettre le champ delegates dans le corps de la requête.

  • LIFETIME : délai avant expiration du nouveau jeton d'accès, exprimé en secondes. Exemple :300s

    Par défaut, la durée de vie maximale du jeton est d'une heure, soit 3 600 secondes. Pour étendre la durée de vie maximale de ces jetons à 12 heures (43 200 secondes), ajoutez le compte de service à une règle d'administration comprenant la contrainte de liste constraints/iam.allowServiceAccountCredentialLifetimeExtension.

Méthode HTTP et URL :

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken

Corps JSON de la requête :

{
  "delegates": [
    DELEGATES
  ],
  "scope": [
    "https://www.googleapis.com/auth/cloud-platform"
  ],
  "lifetime": "LIFETIME"
}

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

Si la requête generateAccessToken a abouti, le corps de la réponse contient un jeton d'accès OAuth 2.0 et une heure d'expiration. Ce jeton d'accès (accessToken) peut alors être utilisé pour authentifier une requête au nom du compte de service jusqu'à ce que l'heure d'expiration spécifiée expireTime soit atteinte : 

{
  "accessToken": "eyJ0eXAi...NiJ9",
  "expireTime": "2020-04-07T15:01:23.045123456Z"
}

Générer des jetons d'identification OpenID Connect

Les jetons d'identification OpenID Connect sont valides pendant 1 heure, soit 3 600 secondes. Pour générer un jeton d'identification pour un compte de service, procédez comme suit :

API

La méthode serviceAccounts.generateIdToken de l'API Service Account Credentials génère un jeton OpenID Connect pour un compte de service.

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

  • SA_NAME : nom du compte de service pour lequel vous souhaitez créer un jeton.
  • PROJECT_ID : ID de votre projet Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project.
  • AUDIENCE_NAME : audience du jeton, généralement l'URL de l'application ou du service auquel le jeton sera appliqué pour autoriser l'accès.

Méthode HTTP et URL : 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:generateIdToken

Corps JSON de la requête :

{
  "audience": "AUDIENCE_NAME",
  "includeEmail": "true"
}

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

Si la requête generateId a abouti, le corps de la réponse contient un jeton d'identification valide pendant une heure. Ce jeton d'accès (token) peut alors être utilisé pour authentifier une requête au nom du compte de service : 

{
  "token": "eyJ0eXAi...NiJ9"
}

Créer un jeton Web JSON (JWT) autosigné

Les jetons Web JSON (JWT) autosignés sont utiles dans divers scénarios. Par exemple :

  • Authentification d'un appel à une API Google, comme indiqué dans le guide d'authentification Google.
  • Communication sécurisée entre des services Google Cloud ou des services autres que Google, comme dans le cas des applications App Engine. Dans un tel scénario, une application est susceptible de signer un jeton qui pourra être validé par une autre application à des fins d'authentification.
  • Traitement d'un compte de service en tant que fournisseur d'identité, via la signature d'un jeton JWT contenant des revendications arbitraires sur un utilisateur, un compte ou un appareil.

Pour générer un jeton JWT autosigné pour un compte de service, procédez comme suit :

API

La méthode serviceAccounts.signJwt de l'API Service Account Credentials signe un jeton JWT à l'aide de la clé privée gérée par le système d'un compte de service.

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

  • SA_NAME : nom du compte de service pour lequel vous souhaitez créer un jeton.
  • PROJECT_ID : ID de votre projet Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project.
  • DELEGATES : si vous utilisez un flux de requête déléguée, consultez la section Spécifier une chaîne de délégation de cette page. Dans le cas d'un flux de requête directe (sans délégation), vous devez omettre le champ delegates dans le corps de la requête.

  • JWT_PAYLOAD : la charge utile JWT à signer. Il s'agit d'un objet JSON contenant un ensemble de revendications JWT. Incluez les revendications nécessaires pour répondre aux besoins du cas d'utilisation souhaité et aux exigences de validation du service que vous appelez. Si vous appelez une API Google, reportez-vous au guide de l'authentification de Google (en anglais) pour connaître les exigences concernant les revendications.

    La revendication exp (heure d'expiration) ne doit pas être fixée au delà de 12 heures dans le futur. Si vous appelez une API Google, la revendication exp ne doit pas être fixée au delà d'une heure dans le futur.

    L'exemple de charge utile suivant contient des revendications pour appeler une API Google, où EXP est un horodatage entier représentant le délai d'expiration :

    { \"iss\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"sub\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"aud\": \"https://firestore.googleapis.com/\", \"iat\": 1529350000, \"exp\": EXP }

Méthode HTTP et URL :

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:signJwt

Corps JSON de la requête :

{
  "delegates": [
    DELEGATES
  ],
  "payload": "JWT_PAYLOAD"
}

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

Si la requête signJwt a abouti, le corps de la réponse contient un jeton JWT signé, ainsi que l'ID de clé de signature utilisé pour signer ce jeton JWT. Vous pouvez utiliser la valeur signedJwt en tant que jeton de support pour authentifier directement une requête émise au nom du compte de service. Le jeton est valide jusqu'à l'heure d'expiration spécifiée dans la requête : 

{
  "keyId": "42ba1e...fc0a",
  "signedJwt": "eyJ0eXAi...NiJ9"
}

Créer un blob autosigné

Les blobs autosignés sont utiles pour les scénarios dans lesquels vous devez transmettre de manière sécurisée des données binaires arbitraires, généralement à des fins d'authentification. Par exemple, si vous souhaitez utiliser un type de protocole ou de jeton personnalisé (autre que JWT), vous pouvez inclure ces données dans un blob signé pour utilisation par un service en aval.

Pour générer un blob autosigné pour un compte de service, procédez comme suit :

API

La méthode serviceAccounts.signBlob de l'API Service Account Credentials signe un blob à l'aide de la clé privée gérée par le système d'un compte de service.

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

  • SA_NAME : nom du compte de service pour lequel vous souhaitez créer un jeton.
  • PROJECT_ID : ID de votre projet Google Cloud. Les ID de projet sont des chaînes alphanumériques, telles que my-project.
  • DELEGATES : si vous utilisez un flux de requête déléguée, consultez la section Spécifier une chaîne de délégation de cette page. Dans le cas d'un flux de requête directe (sans délégation), vous devez omettre le champ delegates dans le corps de la requête.
  • BLOB_PAYLOAD : chaîne d'octets encodée en base64. Exemple : VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cu.

Méthode HTTP et URL :

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:signBlob

Corps JSON de la requête :

{
  "delegates": [
    DELEGATES
  ],
  "payload": "BLOB_PAYLOAD"
}

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

Si la requête signBlob a abouti, le corps de la réponse contient un blob signé, ainsi que l'ID de clé de signature utilisé pour signer ce blob. Vous pouvez utiliser la valeur signedBlob en tant que jeton de support pour authentifier directement une requête émise au nom du compte de service. Le jeton est valide jusqu'à l'expiration de la clé privée gérée par le système d'un compte de service. L'ID de cette clé correspond à la valeur du champ keyId dans la réponse. 

{
  "keyId": "42ba1e...fc0a",
  "signedBlob": "eyJ0eXAi...NiJ9"
}

Spécifier une chaîne de délégation

Lorsque vous utilisez un flux de requête déléguée pour créer des identifiants de compte de service à court terme, le corps de la requête correspondant à chaque API doit spécifier la chaîne de délégation dans l'ordre exact et en respectant le format suivant :

projects/-/serviceAccounts/SA_ID

Remplacez SA_ID par l'ID numérique unique du compte de service ou l'adresse e-mail du compte de service.

Par exemple, si une chaîne de délégation comprend successivement SA_1 (auteur de l'appel), SA_2 (compte délégué), SA_3 (compte délégué) et SA_4, le champ delegates[] doit présenter SA_2 et SA_3 dans l'ordre suivant :

{
  "delegates": [
    "projects/-/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com",
    "projects/-/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com"
  ]
}

L'auteur de l'appel et le compte de service pour lequel l'identifiant est créé ne sont pas inclus dans la chaîne de délégation.