Présentation de l'identité de service

Cette page décrit les deux identités Cloud Run et explique comment les bibliothèques clientes Cloud utilisent l'identité du service pour appeler les API Google Cloud. Cloud Storage, Firestore, Cloud SQL, Pub/Sub et Cloud Tasks sont des exemples de produits Google Cloud disposant de bibliothèques clientes Cloud. Cette page s'adresse aux administrateurs, opérateurs ou développeurs qui gèrent les règles d'administration et l'accès des utilisateurs, ou à toute personne souhaitant en savoir plus sur ces sujets.

Identités Cloud Run

Pour utiliser Cloud Run, Google Cloud exige que l'utilisateur Cloud Run et l'instance Cloud Run possèdent chacun une identité.

  • L'identité de l'utilisateur Cloud Run est appelée compte de déploiement Cloud Run. Lorsque vous gérez une révision ou un job, vous utilisez cette identité pour envoyer des requêtes à l'API Cloud Run Admin.
  • L'identité de l'instance Cloud Run est appelée identité du service Cloud Run. Lorsque le code Cloud Run que vous avez écrit interagit avec les bibliothèques clientes Cloud ou appelle un autre service Cloud Run pour la communication entre services, vous utilisez cette identité pour envoyer des requêtes depuis Cloud Run aux API Google Cloud ou à d'autres services Cloud Run.

Pour accéder aux API Google Cloud et y envoyer des requêtes, ou pour communiquer entre les services, chaque identité doit disposer des autorisations appropriées qui lui sont accordées dans Identity and Access Management (IAM).

Appeler l'API Cloud Run Admin avec le compte déployeur

Vous pouvez appeler l'API Cloud Run Admin à partir de Cloud Run à l'aide du compte de déployeur Cloud Run. Le compte déployeur peut être un compte utilisateur ou un compte de service. Il représente le compte connecté à l'environnement Google Cloud.

Lorsque le compte déployeur utilise Cloud Run, IAM vérifie s'il dispose des autorisations nécessaires pour effectuer l'opération Cloud Run. Le schéma suivant montre comment un compte utilisateur appelle l'API Cloud Run Admin pour déployer une nouvelle révision à partir de la console Google Cloud :

Appelez l'API Cloud Run Admin depuis la console Google Cloud.
Figure 1. Un utilisateur utilise la console Google Cloud pour déployer une nouvelle révision en envoyant une requête avec un jeton d'accès à l'API Cloud Run Admin. Cloud IAM utilise ce jeton d'accès pour vérifier que le compte utilisateur est authentifié pour accéder à l'API Cloud Run Admin avant d'effectuer l'opération.

Appeler les API Google Cloud avec l'identité du service

Lorsqu'une instance Cloud Run interagit avec d'autres services Cloud Run authentifiés par IAM ou appelle des bibliothèques clientes Cloud via le code d'application ou des fonctionnalités intégrées telles que les intégrations Cloud Run ou les montages de volume Cloud Storage, l'environnement Google Cloud utilise les identifiants par défaut de l'application pour détecter automatiquement si l'identité du service Cloud Run est authentifiée pour effectuer l'opération d'API. L'identité du service Cloud Run est un compte de service qui a été attribué comme identité de l'instance Cloud Run lorsque vous déployez une révision ou exécutez un job.

Un compte de service utilisé comme compte déployeur ne servira d'identité de service que si vous configurez le même compte de service dans votre configuration Cloud Run.

Le reste de ce guide explique comment un service ou un job Cloud Run utilise l'identité du service pour appeler les services et les API Google, et y accéder. Pour en savoir plus sur la configuration de l'identité du service, consultez les pages de configuration de l'identité du service pour les services et les jobs.

Types de comptes de service pour l'identité du service

Lorsque votre instance Cloud Run appelle les API Google Cloud pour effectuer les opérations dont elle a besoin, Cloud Run utilise automatiquement un compte de service comme identité de service. Les deux types de comptes de service pouvant être utilisés comme identité de service sont les suivants :

  • Compte de service géré par l'utilisateur (recommandé) : vous créez manuellement ce compte de service et déterminez l'ensemble minimal d'autorisations dont il a besoin pour accéder à des ressources Google Cloud spécifiques. Le compte de service géré par l'utilisateur suit le format SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com.
  • Compte de service Compute Engine par défaut : Cloud Run fournit automatiquement le compte de service Compute Engine par défaut en tant qu'identité de service par défaut. Le compte de service Compute Engine par défaut suit le format PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Éviter le compte de service par défaut lors de la configuration de l'identité du service

Par défaut, le compte de service Compute Engine par défaut est créé automatiquement. Si vous ne spécifiez pas de compte de service lors de la création du service ou du job Cloud Run, Cloud Run l'utilise.

Selon la configuration de vos règles d'administration, le compte de service par défaut peut se voir attribuer automatiquement le rôle Éditeur sur votre projet. Nous vous recommandons vivement de désactiver l'attribution automatique des rôles en appliquant la contrainte de règle d'administration iam.automaticIamGrantsForDefaultServiceAccounts. Si vous avez créé votre organisation après le 3 mai 2024, cette contrainte est appliquée par défaut.

Si vous désactivez l'attribution automatique de rôles, vous devez choisir les rôles à attribuer aux comptes de service par défaut, puis attribuer ces rôles vous-même.

Si le compte de service par défaut dispose déjà du rôle Éditeur, nous vous recommandons de le remplacer par des rôles moins permissifs. Pour modifier les rôles du compte de service en toute sécurité, utilisez Policy Simulator pour voir l'impact de la modification, puis attribuez et révoquez les rôles appropriés.

Fonctionnement de l'identité de service

Lorsque votre code appelle ou envoie des requêtes aux bibliothèques clientes Cloud, voici ce qui se produit :

  1. Les bibliothèques clientes détectent qu'une requête est envoyée à une API Google Cloud ou à des bibliothèques clientes Cloud, et demandent un jeton d'accès OAuth 2.0 pour l'identité du service auprès du serveur de métadonnées de l'instance.
  2. Le serveur de métadonnées d'instance fournit un jeton d'accès IAM pour le compte de service configuré en tant qu'identité de service.
  3. La requête adressée à l'API Google Cloud est envoyée avec un jeton d'accès OAuth 2.0.
  4. Cloud IAM vérifie l'identité du service référencée dans le jeton d'accès pour obtenir les autorisations nécessaires, et vérifie les liaisons de règles avant de transférer l'appel au point de terminaison de l'API.
  5. L'API Google Cloud effectue l'opération.
Appelez l'API Google Cloud à partir de Cloud Run.
Figure 1. Cloud Run génère un jeton d'accès à partir du serveur de métadonnées, et IAM utilise ce jeton d'accès pour vérifier que l'identité du service Cloud Run attribuée est authentifiée pour accéder aux API Google Cloud.

Générer un jeton d'accès pour la requête Cloud Run afin d'appeler les API Google Cloud

Si votre code Cloud Run utilise les bibliothèques clientes Cloud, vous pouvez configurer l'identité du service dans Cloud Run en attribuant un compte de service lors du déploiement ou de l'exécution. La bibliothèque peut ainsi acquérir automatiquement un jeton d'accès pour authentifier la requête de votre code. Si votre code Cloud Run communique avec d'autres services Cloud Run authentifiés, vous devez ajouter le jeton d'accès à vos requêtes.

Pour attribuer un compte de service en tant qu'identité de service, consultez les guides suivants :

Toutefois, si vous utilisez votre propre code personnalisé ou si vous devez envoyer des requêtes de manière programmatique, vous pouvez utiliser le serveur de métadonnées directement pour récupérer manuellement les jetons d'identité et les jetons d'accès décrits dans la section suivante. Notez que vous ne pouvez pas interroger ce serveur directement à partir de votre ordinateur local, car le serveur de métadonnées n'est disponible que pour les charges de travail exécutées sur Google Cloud.

Récupérer des jetons d'identité et d'accès à l'aide du serveur de métadonnées

Voici les deux types de jetons que vous pouvez récupérer avec le serveur de métadonnées :

Pour récupérer un jeton, suivez les instructions de l'onglet correspondant au type de jeton que vous utilisez :

Jetons d'accès

Par exemple, si vous souhaitez créer un sujet Pub/Sub, utilisez la méthode projects.topics.create.

  1. Utilisez le serveur Compute Metadata pour récupérer un jeton d'accès :

    curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
    --header "Metadata-Flavor: Google"

    Ce point de terminaison renvoie une réponse JSON avec un attribut access_token.

  2. Dans votre requête de protocole HTTP, la requête doit être authentifiée à l'aide d'un jeton d'accès dans l'en-tête Authorization :

    PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
Authorization: Bearer ACCESS_TOKEN

    Où :

    • PROJECT_ID est l'ID de votre projet.
    • TOPIC_ID est l'ID de votre sujet.
    • ACCESS_TOKEN correspond au jeton d'accès que vous avez récupéré à l'étape précédente.

    Réponse :

    {
    "name": "projects/PROJECT_ID/topics/TOPIC_ID"
}

Jetons d'ID

Utilisez le serveur Compute Metadata pour récupérer un jeton d'identité avec une audience spécifique :

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
    --header "Metadata-Flavor: Google"

Où AUDIENCE est l'audience JWT demandée.

Pour les services Cloud Run, l'audience doit être l'URL du service que vous appelez ou une audience personnalisée, telle qu'un domaine personnalisé, configurée pour le service.

https://service.domain.com

Pour les autres ressources, il s'agit probablement de l'ID client OAuth d'une ressource protégée par IAP :

1234567890.apps.googleusercontent.com

Étapes suivantes