Comptes de service

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 instance de machine virtuelle (VM), et non 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, une VM Compute Engine peut s'exécuter en tant que compte de service, et ce compte peut recevoir les autorisations requises pour accéder aux ressources dont il a besoin. Dans ce cas, le compte de service constitue l'identité du service, tandis que les autorisations qui lui sont accordées déterminent les ressources auxquelles il 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 auprès de Google.
  • 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 ne sont pas des membres de votre domaine Google Workspace. Si vous partagez des éléments Google Workspace (tels que des documents ou des événements) avec tous les membres 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 :

Clés de compte de service

Chaque compte de service est associé à deux ensembles de paires de clés RSA publiques/privées permettant l'authentification à Google : des clés gérées par Google et des clés gérées par l'utilisateur.

Clés gérées par Google

Les paires de clés gérées par Google impliquent que Google stocke à la fois les parties publique et privée des clés, et les alterne régulièrement (chaque clé pouvant être utilisée pour la signature pendant deux semaines maximum). De plus, la clé privée est toujours conservée à titre de caution et n'est jamais directement accessible. Cloud IAM fournit des API permettant d'utiliser ces clés pour signer au nom du compte de service. Pour en savoir plus, consultez la page Créer des identifiants de compte de service éphémères.

Clés gérées par l'utilisateur

Les paires de clés gérées par l'utilisateur impliquent de posséder à la fois les parties publique et privée d'une paire de clés. Vous pouvez créer une ou plusieurs paires de clés gérées par l'utilisateur (également connues sous le nom de clés "externes") qui pourront être utilisées hors de Google Cloud. Google ne stocke que la partie publique d'une clé gérée par l'utilisateur.

En outre, vous pouvez créer une clé publique au format approprié et l'importer dans Google, où elle est associée de manière permanente au compte de service spécifié. Lorsque vous devez effectuer des opérations de signature au nom de ce compte de service, par exemple lors de la création de clés de compte de service, la clé publique importée est utilisée.

La partie privée d'une paire de clés gérée par l'utilisateur est généralement utilisée avec les identifiants par défaut de l'application. La clé privée permet ensuite l'authentification serveur à serveur des applications.

Avec les clés gérées par l'utilisateur, vous êtes responsable de la sécurité de la clé privée ainsi que d'autres opérations de gestion telles que la rotation des clés. Les clés gérées par l'utilisateur peuvent être gérées à partir de l'API Cloud IAM, de l'outil de ligne de commande gcloud ou de la page des comptes de service dans Google Cloud Console. Afin de faciliter la rotation des clés, vous pouvez créer jusqu'à 10 clés par compte de service.

Pensez à utiliser Cloud Key Management Service (Cloud KMS) pour gérer vos clés en toute sécurité.

Empêcher la création de clés gérées par l'utilisateur

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 membres de créer des clés de compte de service gérées par l'utilisateur.
  • constraints/iam.disableServiceAccountKeyUpload : empêche les membres 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 Cloud Console ou de l'outil de ligne de commande gcloud. 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 Cloud Console. 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 IAM de votre projet, dans les journaux d'audit ou sur la page "IAM" de Cloud Console.

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

Exemple :

  • Agent de service des API Google. Votre projet est susceptible de contenir 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.

  • 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 IAM du projet.

  • Autres comptes de service gérés par Google. Votre projet peut contenir d'autres comptes de service gérés par Google qui agissent au nom de services individuels. Ces comptes de service sont parfois 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.

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

Toutefois, les comptes de service sont également des ressources qui acceptent les stratégies IAM. Par conséquent, vous pouvez autoriser d'autres membres à 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 membres, 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 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 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 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 Cloud IAM 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.

Le rôle de créateur de jetons du compte de service

Ce rôle permet d'emprunter l'identité d'un compte de service pour créer des jetons d'accès OAuth2, ou pour signer des blobs ou des jetons JWT.

Niveaux d'accès

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 l'outil gcloud 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

Pour découvrir les bonnes pratiques relatives à l'utilisation des comptes de service, consultez la section Comprendre les comptes de service.

Vous lirez également avec profit les pages suivantes :

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