Comptes de service

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

Cette page décrit les différents types de comptes de service, ainsi que les rôles IAM disponibles pour ces comptes.

Avant de commencer

  • Explorez les concepts fondamentaux de Cloud IAM.

Que sont les comptes de service ?

Un compte de service est un type particulier de compte utilisé par une application ou une charge de travail de calcul, telle qu'une instance de machine virtuelle (VM) Compute Engine, plutôt que par une personne. Les applications utilisent les comptes de service pour effectuer des appels d'API autorisés soit en tant que compte de service, soit en tant qu'utilisateurs Google Workspace ou Cloud Identity via la délégation au niveau du domaine.

Par exemple, un compte de service peut être associé à une VM Compute Engine, de sorte que les applications exécutées sur cette VM puissent s'authentifier en tant que compte de service. De plus, le compte de service peut se voir attribuer des rôles IAM lui permettant d'accéder aux ressources. Le compte de service sert d'identité à l'application, et les rôles du compte de service contrôlent quelles sont les ressources auxquelles l'application peut accéder.

Un compte de service est identifié par son adresse e-mail, qui est unique au compte.

Différences entre un compte de service et un compte utilisateur

Les comptes de service diffèrent des comptes utilisateur sur plusieurs points :

  • Les comptes de service n'ont pas de mot de passe, et la connexion à ces comptes ne peut être effectuée via un navigateur ou des cookies.
  • Les comptes de service sont associés à des paires de clés RSA publiques/privées permettant l'authentification à Google et la signature de données.
  • Vous pouvez autoriser d'autres utilisateurs ou comptes de service à emprunter l'identité d'un compte de service.
  • Contrairement aux comptes utilisateur, les comptes de service n'appartiennent pas à votre domaine Google Workspace. Si vous partagez des éléments Google Workspace, tels que des documents ou des événements, avec l'ensemble de votre domaine Google Workspace, ces éléments ne sont pas partagés avec les comptes de service. De même, les éléments Google Workspace créés par un compte de service ne sont pas créés dans votre domaine Google Workspace. Par conséquent, vos administrateurs Google Workspace et Cloud Identity ne peuvent pas être propriétaires de ces éléments ni les gérer.

Empêcher la création de comptes de service

Vous pouvez empêcher la création de comptes de service en appliquant la contrainte de règle d'administration constraints/iam.disableServiceAccountCreation dans une organisation, un projet ou un dossier.

Avant d'appliquer cette contrainte, tenez compte des restrictions suivantes :

Comptes de service et groupes Google

Vous pouvez ajouter des comptes de service à un groupe Google, puis attribuer des rôles au groupe. Toutefois, l'ajout de comptes de service à des groupes n'est pas considéré comme une bonne pratique. Les comptes de service sont utilisés par des applications, et chaque application est susceptible d'avoir ses propres conditions d'accès.

Types de clés pour les comptes de service

Chaque compte de service est associé à une paire de clés RSA publique/privée. L'API Service Account Credentials utilise cette paire de clés interne pour créer des identifiants de compte de service éphémères, et pour signer des blobs et des jetons Web JSON (JWT). Cette paire de clés est appelée paire de clés gérée par Google.

Vous pouvez également créer plusieurs paires de clés RSA publiques/privées, appelées paires de clés gérées par l'utilisateur, et utiliser la clé privée pour vous authentifier auprès des API Google. Cette clé privée est appelée clé de compte de service.

Paires de clés gérées par Google

Les paires de clés gérées par Google sont utilisées par l'API Service Account Credentials ainsi que par les services Google Cloud tels qu'App Engine et Compute Engine pour générer des identifiants de courte durée pour les comptes de service.

Les paires de clés gérées par Google sont automatiquement alternées et utilisées pour la signature pendant deux semaines maximum. Le processus de rotation est probabiliste. L'utilisation de la nouvelle clé augmentera et diminuera progressivement au cours de la durée de vie de la clé.

La clé privée d'une paire de clés gérée par Google est toujours conservée à titre de caution et vous ne pouvez jamais y accéder directement.

La clé publique d'une paire de clés gérée par Google est accessible au public. Ainsi, quiconque peut valider les signatures créées avec la clé privée. Vous pouvez accéder à la clé publique dans différents formats :

  • Certificat X.509 : https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • Clé Web JSON (JWK) : https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • Format brut : https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Si vous téléchargez et mettez en cache la clé publique, nous vous recommandons de la mettre en cache pendant 24 heures maximum afin de vous assurer que vous disposez toujours de la clé actuelle. Quelle que soit la date à laquelle vous avez récupéré la clé publique, celle-ci reste valide pendant au moins 24 heures après sa récupération.

Paires de clés gérées par l'utilisateur

Vous pouvez créer des paires de clés gérées par l'utilisateur pour un compte de service, puis vous authentifier avec les API Google à l'aide de la clé privée de chaque paire de clés. Cette clé privée est appelée clé de compte de service. Chaque compte de service peut comporter jusqu'à 10 clés. Google ne stocke que la partie publique d'une paire de clés gérée par l'utilisateur.

Il existe plusieurs façons de créer une paire de clés gérée par l'utilisateur pour un compte de service :

Les clés gérées par l'utilisateur constituent des identifiants extrêmement puissants. Si elles ne sont pas gérées correctement, elles peuvent présenter un risque de sécurité. Pour limiter l'utilisation de clés gérées par l'utilisateur, vous pouvez appliquer les contraintes liées aux règles d'administration suivantes à une organisation, un projet ou un dossier :

  • constraints/iam.disableServiceAccountKeyCreation : empêche les comptes principaux de créer des clés de compte de service gérées par l'utilisateur.
  • constraints/iam.disableServiceAccountKeyUpload : empêche les comptes principaux d'importer une clé publique pour un compte de service.

Si vous appliquez ces contraintes parce que vous utilisez la fédération d'identité de charge de travail, envisagez d'utiliser les contraintes de règles d'administration pour la fédération d'identité de charge de travail afin de spécifier quels fournisseurs d'identité sont autorisés.

Types de comptes de service

Comptes de service gérés par l'utilisateur

Vous pouvez créer des comptes de service gérés par l'utilisateur dans votre projet à l'aide de l'API Cloud IAM, de la console Google Cloud ou de Google Cloud CLI. Vous êtes responsable de la gestion et de la sécurisation de ces comptes.

Par défaut, vous pouvez créer jusqu'à 100 comptes de service gérés par l'utilisateur dans un projet. Si ce quota ne répond pas à vos besoins, vous pouvez demander une augmentation de quota à l'aide de la console Google Cloud. Les comptes de service par défaut décrits sur cette page ne sont pas comptabilisés dans ce quota.

Lorsque vous créez un compte de service géré par l'utilisateur dans votre projet, vous choisissez un nom pour ce compte de service. Ce nom apparaît dans l'adresse e-mail qui identifie le compte de service, au format suivant :

service-account-name@project-id.iam.gserviceaccount.com

Comptes de service par défaut

Lorsque vous activez ou utilisez des services Google Cloud, ceux-ci créent des comptes de service gérés par l'utilisateur, qui permettent au service de déployer des tâches qui accèdent à d'autres ressources Google Cloud. Ces comptes sont appelés comptes de service par défaut.

Si votre application s'exécute dans un environnement Google Cloud disposant d'un compte de service par défaut, elle peut utiliser les identifiants du compte de service par défaut pour appeler les API Google Cloud. Vous pouvez également créer votre propre compte de service géré par l'utilisateur et vous en servir pour vous authentifier. Pour en savoir plus, consultez la section Rechercher automatiquement des identifiants.

Le tableau suivant répertorie les services qui créent des comptes de service par défaut :

Service Nom du compte de service Adresse e-mail
App Engine, et tout service Google Cloud utilisant App Engine Compte de service App Engine par défaut project-id@appspot.gserviceaccount.com
Compute Engine, et tout service Google Cloud utilisant Compute Engine Compte de service Compute Engine par défaut project-number-compute@developer.gserviceaccount.com

Comptes de service gérés par Google

Certains services Google Cloud ont besoin d'accéder à vos ressources pour pouvoir agir en votre nom. Par exemple, lorsque vous exécutez un conteneur à l'aide de Cloud Run, le service doit avoir accès à tous les sujets Pub/Sub pouvant déclencher le conteneur.

Pour répondre à ce besoin, Google crée et gère des comptes de service pour de nombreux services Google Cloud. Ces comptes sont appelés comptes de service gérés par Google. Il est possible que des comptes de service gérés par Google s'affichent dans la stratégie d'autorisation de votre projet, dans les journaux d'audit ou sur la page "IAM" de la console Google Cloud.

Les comptes de service gérés par Google ne sont pas répertoriés sur la page Comptes de service de la console Google Cloud.

Exemple :

  • Agent de service des API Google. La stratégie d'autorisation de votre projet est susceptible de faire référence à un compte de service nommé "Agent de service des API Google", avec une adresse e-mail au format suivant : project-number@cloudservices.gserviceaccount.com

    Ce compte de service exécute des processus Google internes en votre nom. Le rôle Éditeur (roles/editor) lui est automatiquement attribué sur le projet.

  • Autres agents de service La stratégie d'autorisation de votre projet peut faire référence à d'autres comptes de service gérés par Google qui agissent au nom de services individuels. Ces comptes de service sont appelés agents de service. Des rôles peuvent être automatiquement attribués à ces agents de service. Le nom de ces rôles se termine généralement par serviceAgent.

    Pour obtenir la liste complète des agents de service et des rôles qui leur sont automatiquement attribués, consultez la page Agents de service.

  • Gestionnaire de rôles pour les comptes de service gérés par Google. Vos journaux d'audit pour IAM peuvent faire référence au compte de service service-agent-manager@system.gserviceaccount.com.

    Ce compte de service gère les rôles attribués aux autres comptes de service gérés par Google. Il n'est visible que dans les journaux d'audit.

    Par exemple, si vous utilisez une nouvelle API, Google peut créer automatiquement un compte de service dont il assure la gestion et lui attribuer des rôles dans votre projet. L'attribution de ces rôles génère une entrée de journal d'audit, qui indique que service-agent-manager@system.gserviceaccount.com a défini la stratégie d'autorisation du projet.

Emplacements des comptes de service

Chaque compte de service est situé dans un projet. Une fois que vous avez créé un compte de service, vous ne pouvez pas le déplacer vers un autre projet.

Il existe plusieurs façons d'organiser vos comptes de service dans des projets :

  • Créez des comptes de service et des ressources dans le même projet.

    Cette approche facilite les premiers pas avec les comptes de service. Cependant, il peut être difficile d'assurer le suivi de vos comptes de service lorsqu'ils sont répartis sur de nombreux projets.

  • Centralisez les comptes de service dans un projet distinct.

    Cette approche place tous les comptes de service de votre organisation dans un petit nombre de projets, ce qui peut faciliter la gestion des comptes de service. Cependant, cette approche nécessite une configuration supplémentaire si vous associez des comptes de service aux ressources dans d'autres projets, ce qui permet à ces ressources d'utiliser le compte de service comme identité.

    Lorsqu'un compte de service se trouve dans un projet et qu'il accède à une ressource d'un autre projet, vous devez généralement activer l'API pour cette ressource dans les deux projets. Par exemple, si vous disposez d'un compte de service dans le projet my-service-accounts et d'une instance Cloud SQL dans le projet my-application, vous devez activer l'API Cloud SQL dans les projets my-service-accounts et my-application.

    Par défaut, vous pouvez créer jusqu'à 100 comptes de service dans un projet. Si vous devez créer des comptes de service supplémentaires, demandez une augmentation de quota.

Autorisations de compte de service

Les comptes de service sont à la fois des identités et des ressources.

Comme les comptes de service sont des identités, vous pouvez autoriser un compte de service à accéder aux ressources de votre projet en lui attribuant un rôle, comme vous le feriez pour n'importe quel autre compte principal. Par exemple, si vous souhaitez autoriser le compte de service de votre application à accéder aux objets d'un bucket Cloud Storage, vous pouvez attribuer au compte de service le rôle "Lecteur des objets Storage" (roles/storage.objectViewer) sur le bucket.

Pour en savoir plus sur l'attribution de rôles aux comptes principaux, y compris les comptes de service, consultez la page Attribuer, modifier et révoquer les accès.

Toutefois, les comptes de service sont également des ressources qui acceptent les stratégies d'autorisation. Par conséquent, vous pouvez autoriser d'autres comptes principaux à accéder à un compte de service en leur attribuant un rôle sur le compte de service ou sur l'une des ressources parentes du compte de service. Par exemple, pour permettre à un utilisateur d'emprunter l'identité d'un compte de service, vous pouvez lui accorder le rôle d'utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service.

Pour en savoir plus sur l'attribution de rôles aux comptes principaux, y compris les comptes de service, consultez la page Attribuer, modifier et révoquer les accès.

Pour en savoir plus sur l'attribution de rôles sur des comptes de service, consultez la page Gérer l'emprunt d'identité d'un compte de service.

Rôle Utilisateur du compte de service

Vous pouvez attribuer le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) au niveau du projet pour tous les comptes de service de ce projet, ou au niveau du compte de service.

  • En attribuant le rôle Utilisateur du compte de service à un utilisateur pour un projet, vous permettez à cet utilisateur d'accéder à tous les comptes de service du projet, y compris ceux pouvant être créés ultérieurement.

  • Le rôle Utilisateur du compte de service attribué à un utilisateur pour un compte de service spécifique ne permet à cet utilisateur d'accéder qu'à ce compte de service.

Les autorisations de ce rôle incluent l'autorisation iam.serviceAccounts.actAs. En conséquence, les utilisateurs auxquels le rôle Utilisateur du compte de service est attribué sur un compte de service peuvent accéder indirectement à toutes les ressources auxquelles le compte de service a lui-même accès. Par exemple, si le compte de service s'est vu attribuer le rôle Administrateur de Compute (roles/compute.admin), un utilisateur ayant le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur ce compte de service peut agir en tant que ce compte de service pour démarrer une instance Compute Engine. Dans ce cas de figure, l'utilisateur emprunte l'identité du compte de service pour pouvoir réaliser des tâches avec les rôles et autorisations qui lui ont été accordés.

Pour en savoir plus sur l'attribution à des utilisateurs de rôles sur des comptes de service, consultez la page Gérer l'emprunt d'identité d'un compte de service.

Les comptes de service représentent votre sécurité au niveau du service. La sécurité du service est déterminée par les personnes disposant des rôles Cloud IAM nécessaires pour gérer et utiliser les comptes de service, ainsi que par les personnes qui détiennent les clés externes privées associées à ces comptes de service. Voici quelques-unes des pratiques recommandées pour assurer la sécurité :

  • Utilisez l'API Cloud IAM pour auditer les comptes de service ainsi que les clés et les stratégies d'autorisation associées à ces comptes.
  • Si vos comptes de service n'ont pas besoin de clés externes, supprimez-les.
  • Si les utilisateurs n'ont pas besoin d'être autorisés à gérer ou utiliser des comptes de service, supprimez-les de la stratégie d'autorisation applicable.
  • Assurez-vous que les comptes de service disposent du nombre minimal d'autorisations nécessaires. Utilisez les comptes de service par défaut avec prudence, car ils se voient attribuer automatiquement le rôle d'éditeur (roles/editor) sur le projet.

Pour en savoir plus sur les bonnes pratiques, consultez la section Comprendre les comptes de service.

Rôle Créateur de jetons du compte de service

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 (OIDC).
  • 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.

Rôle Utilisateur Workload Identity

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 (OIDC).

Access scopes

Les niveaux d'accès constituent une ancienne méthode de spécification des autorisations pour une instance de machine virtuelle (VM) Compute Engine. Ils définissent les champs d'application OAuth par défaut utilisés dans les requêtes de gcloud CLI et des bibliothèques clientes.

Google Cloud utilise désormais IAM plutôt que des niveaux d'accès pour spécifier des autorisations pour les instances Compute Engine. Toutefois, vous devez toujours définir un champ d'application d'accès lorsque vous configurez une instance pour usurper son identité.

Pour en savoir plus, consultez la documentation Compute Engine.

Identifiants de compte de service à court terme

Vous avez la possibilité de créer des identifiants à court terme vous permettant d'emprunter l'identité d'un compte de service Google Cloud. Ces identifiants peuvent servir à authentifier les appels vers les API Google Cloud ou vers des API autres que Google.

Le cas d'utilisation le plus courant de ces identifiants consiste à déléguer temporairement l'accès aux ressources Google Cloud à l'échelle de différents projets, organisations ou comptes. Par exemple, au lieu de fournir à un appelant externe les identifiants permanents d'un compte de service à privilèges élevés, vous pouvez lui accorder un accès d'urgence à titre temporaire. De même, un appelant externe pourra emprunter l'identité d'un compte de service désigné disposant d'autorisations moindres sans avoir besoin des identifiants d'un compte de service à privilèges plus élevés.

Pour en savoir plus, consultez la page Créer des identifiants de compte de service à court terme.

Fédération d'identité de charge de travail

Vous pouvez accorder l'autorisation d'usurper l'identité d'un compte de service aux identités d'une charge de travail exécutée en dehors de Google Cloud, par exemple sur Amazon Web Services (AWS) ou Microsoft Azure. Ainsi, vous pouvez accéder directement aux ressources à l'aide d'identifiants éphémères, plutôt que d'avoir à utiliser une clé de compte de service.

Pour en savoir plus, consultez la page Fédération d'identité de charge de travail.

Identifiants par défaut de l'application

Les identifiants par défaut de l'application sont un outil que les bibliothèques clientes Google Cloud utilisent pour détecter automatiquement les identifiants du compte de service. Vous pouvez spécifier une clé de compte de service dans une variable d'environnement et les identifiants par défaut de l'application utiliseront automatiquement cette clé de compte de service. Si vous ne spécifiez pas de clé, les identifiants par défaut de l'application utilisent le compte de service associé à la ressource qui exécute votre code, ou le compte de service par défaut du service qui exécute votre code.

Pour en savoir plus, consultez la section Rechercher automatiquement des identifiants.

Étape suivante

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Essai gratuit