Présentation des comptes de service

Cette page explique en quoi consistent les comptes de service et décrit les points importants à prendre en compte pour gérer vos comptes de service à chaque étape de leur cycle de vie.

Que sont les comptes de service ?

Un compte de service est un type de compte particulier généralement utilisé par une application ou une charge de travail de calcul, telle qu'une instance Compute Engine, plutôt que par une personne. Un compte de service est identifié par son adresse e-mail, qui est unique au compte.

Les applications utilisent les comptes de service pour effectuer des appels d'API autorisés en s'authentifiant 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. Lorsqu'une application s'authentifie en tant que compte de service, elle a accès à toutes les ressources auxquelles le compte de service est autorisé à accéder.

La façon la plus courante de permettre à une application de s'authentifier en tant que compte de service consiste à associer un compte de service à la ressource exécutant l'application. Par exemple, vous pouvez associer un compte de service à une instance Compute Engine pour que les applications exécutées sur cette instance puissent s'authentifier en tant que compte de service. Ensuite, vous pouvez attribuer des rôles IAM au compte de service pour permettre au compte de service et, par extension, aux applications de l'instance, d'accéder aux ressources Google Cloud.

L'association d'un compte de service n'est pas la seule façon de permettre aux applications de s'authentifier en tant que comptes de service. Par exemple, vous pouvez configurer la fédération d'identité de charge de travail pour permettre aux charges de travail externes de s'authentifier en tant que comptes de service, ou créer une clé de compte de service et l'utiliser dans n'importe quel environnement pour obtenir des jetons d'accès OAuth 2.0.

Pour en savoir plus sur l'authentification des comptes de service pour les applications, consultez la Présentation des identités pour les charges de travail.

Les comptes principaux, tels que les utilisateurs et d'autres comptes de service, peuvent également s'authentifier en tant que comptes de service. Pour plus d'informations, consultez la section Emprunter l'identité d'un compte de service sur cette page.

Types de comptes de service

Dans Google Cloud, il existe plusieurs types de comptes de service :

  • Comptes de service gérés par l'utilisateur : comptes de service que vous créez et gérez. Ces comptes de service sont souvent utilisés comme identités pour les charges de travail.

  • Comptes de service par défaut : comptes de service gérés par l'utilisateur créés automatiquement lorsque vous activez certains services Google Cloud. Vous êtes responsable de la gestion de ces comptes de service.

  • Comptes de service gérés par Google : comptes de service créés et gérés par Google qui autorisent les services à accéder aux ressources en votre nom.

Pour en savoir plus sur les différents types de comptes de service, consultez la page Types de comptes de service.

Identifiants du compte de service

Les applications et les comptes principaux s'authentifient en tant que compte de service en effectuant l'une des opérations suivantes :

  • Obtenir des identifiants éphémères. Dans de nombreux cas, tels que des comptes de service et des commandes associés à l'aide de l'option --impersonate-service-account de gcloud CLI, ces identifiants sont obtenus automatiquement. Vous n'avez pas besoin de les créer ni de les gérer vous-même.
  • Utiliser une clé de compte de service pour signer un jeton Web JSON (JWT) et l'échanger contre un jeton d'accès Comme les clés de compte de service peuvent présenter un risque pour la sécurité si elles ne sont pas gérées correctement, vous devez choisir une alternative plus sécurisée dans la mesure du possible.

Pour en savoir plus sur l'authentification des comptes de service, consultez la page Identifiants du compte de service.

Emprunter l'identité d'un compte de service

Lorsqu'un compte principal authentifié, tel qu'un utilisateur ou un autre compte de service, s'authentifie en tant que compte de service pour obtenir les autorisations de ce dernier, cela s'appelle emprunter l'identité du compte de service. Emprunter l'identité d'un compte de service permet à un compte principal authentifié d'accéder à ce que le compte de service peut accéder. Seuls les comptes principaux authentifiés disposant des autorisations appropriées peuvent emprunter l'identité des comptes de service.

L'emprunt d'identité est utile lorsque vous souhaitez modifier les autorisations d'un utilisateur sans modifier vos stratégies IAM (Identity and Access Management). Par exemple, vous pouvez utiliser l'emprunt d'identité pour accorder temporairement à un utilisateur un accès avec privilèges élevés ou pour tester si un ensemble spécifique d'autorisations est suffisant pour une tâche. Vous pouvez également emprunter l'identité pour développer localement des applications qui ne peuvent s'exécuter qu'en tant que compte de service, ou pour authentifier des applications exécutées en dehors de Google Cloud.

Pour en savoir plus sur l'emprunt d'identité d'un compte de service, consultez la section Emprunter l'identité d'un compte de service.

Comptes de service et domaines Google Workspace

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.

Autorisations de compte de service

Les comptes de service sont des comptes principaux. Cela signifie que vous pouvez autoriser des comptes de service à accéder aux ressources Google Cloud. Vous pourriez par exemple attribuer à un compte de service le rôle Administrateur de Compute (roles/compute.admin) sur un projet. Le compte de service pourrait alors gérer les ressources Compute Engine dans ce projet.

Toutefois, les comptes de service sont également des ressources. Cela signifie que vous pouvez autoriser d'autres comptes principaux à accéder au compte de service. Par exemple, vous pouvez attribuer à un utilisateur le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur un compte de service pour lui permettre d'associer ce compte de service à des ressources. Vous pouvez aussi attribuer à un utilisateur le rôle Administrateur de compte de service (roles/iam.serviceAccountAdmin) pour lui permettre d'effectuer des actions telles qu'afficher, modifier, désactiver ou supprimer le compte de service.

Les sections suivantes décrivent comment gérer des comptes de service en tant que comptes principaux et en tant que ressources.

Comptes de service en tant que comptes principaux

Comme les comptes de service sont des comptes principaux, 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.

Comme pour tous les types de comptes principaux, vous ne devez accorder au compte de service que le nombre minimal d'autorisations requises pour atteindre son objectif.

Comme pour les autres comptes principaux, 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.

Pour savoir comment attribuer des rôles aux comptes principaux, y compris aux comptes de service, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Comptes de service en tant que ressources

Les comptes de service sont également des ressources qui peuvent avoir leurs propres 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 Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator) sur le compte de service.

Lorsque vous attribuez un rôle permettant à un utilisateur d'emprunter l'identité d'un compte de service, gardez à l'esprit que l'utilisateur peut accéder à toutes les ressources auxquelles le compte de service peut accéder. Soyez prudent lorsque vous autorisez des utilisateurs à emprunter l'identité de comptes de service à privilèges élevés, tels que les comptes de service par défaut Compute Engine et App Engine.

Pour en savoir plus sur les rôles que vous pouvez attribuer aux comptes principaux sur les comptes de service, consultez la section Autorisations de compte de service.

Pour savoir comment attribuer un rôle à un compte principal sur un compte de service, consultez la section Gérer l'accès aux comptes de service.

Cycle de vie du compte de service

Lorsque vous gérez vos projets, vous allez probablement créer, gérer et supprimer de nombreux comptes de service différents. Cette section décrit les éléments clés à prendre en compte pour gérer vos comptes de service aux différents stades de leur cycle de vie.

Où créer 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.

Pour savoir comment créer un compte de service, consultez la section Créer des comptes de service.

Empêcher la création de comptes de service

Pour mieux contrôler où sont créés les comptes de service, il est possible d'empêcher la création de comptes de service dans certains projets de votre organisation.

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 :

  • Si vous appliquez cette contrainte dans un projet ou dans tous les projets d'une organisation, certains services Google Cloud ne peuvent pas créer de comptes de service par défaut. Par conséquent, si le projet exécute des charges de travail nécessitant de s'authentifier en tant que compte de service, il est possible que le projet ne contienne pas de compte de service utilisable par la charge de travail.

    Pour résoudre ce problème, vous pouvez activer l'emprunt d'identité des comptes de service entre les projets. Lorsque vous activez cette fonctionnalité, vous pouvez créer des comptes de service dans un projet centralisé, puis associer ces comptes de service à des ressources situées dans d'autres projets. Les charges de travail exécutées sur ces ressources peuvent utiliser les comptes de service associés pour s'authentifier, ce qui rend les comptes de service par défaut inutiles.

  • Certaines fonctionnalités, telles que la fédération d'identité de charge de travail, nécessitent la création de comptes de service.

    Si vous n'utilisez pas la fédération d'identité de charge de travail, envisagez d'utiliser les contraintes de règle d'administration pour bloquer la fédération depuis tous les fournisseurs d'identité.

Effectuer le suivi des comptes de service

Au fil du temps, à mesure que vous créez de plus en plus de comptes de service, vous risquez de ne plus savoir dans quel but un compte de service est utilisé.

Le nom à afficher d'un compte de service est un bon moyen de capturer des informations supplémentaires sur le compte de service, telles que la finalité du compte de service ou la personne à contacter pour le compte. Pour les nouveaux comptes de service, vous pouvez renseigner le nom à afficher lors de la création du compte de service. Pour les comptes de service existants, utilisez la méthode serviceAccounts.update() afin de modifier le nom à afficher.

Utiliser des comptes de service avec Compute Engine

Les instances Compute Engine doivent être exécutées en tant que comptes de service pour avoir accès à d'autres ressources Google Cloud. Pour sécuriser vos instances Compute Engine, tenez compte des points suivants :

  • Vous pouvez créer des instances dans le même projet avec différents comptes de service. Pour modifier le compte de service d'une instance après sa création, utilisez la méthode instances.setServiceAccount.

  • Pour configurer une autorisation pour des comptes de service associés, vous devez configurer des niveaux d'accès en plus des rôles IAM.

  • Étant donné que les instances dépendent de leurs comptes de service pour accéder aux ressources Google Cloud, évitez de supprimer les comptes de service tant qu'ils sont encore utilisés par des instances en cours d'exécution.

Pour en savoir plus sur l'utilisation des comptes de service avec Compute Engine, consultez la section Comptes de service dans la documentation Compute Engine.

Identifier les comptes de service inutilisés

Après un certain temps, il se peut que vous disposiez de comptes de service dans vos projets que vous n'utilisez plus.

Les comptes de service inutilisés créent un risque de sécurité inutile. Nous vous recommandons donc de désactiver les comptes de service inutilisés, puis de supprimer les comptes de service lorsque vous êtes sûr de ne plus en avoir besoin. Pour identifier les comptes de service inutilisés, procédez comme suit :

  • La section Insights sur les comptes de service indique les comptes de service de votre projet qui n'ont pas été authentifiés au cours des 90 derniers jours.
  • L'outil Activity Analyzer vous permet de vérifier à quel moment une clé ou un compte de service a été utilisé pour la dernière fois.

Vous pouvez également exploiter les métriques d'utilisation des comptes de service pour effectuer le suivi de l'utilisation des comptes de service et des clés en général.

Si vous êtes un client Security Command Center Premium, vous pouvez utiliser Event Threat Detection pour recevoir une notification lorsqu'un compte de service dormant déclenche une action. Les comptes de service dits "dormants" sont des comptes de service inactifs depuis plus de 180 jours. Une fois qu'un compte de service est utilisé, il n'est plus dormant.

Supprimer des comptes de service

Avant de supprimer un compte de service, désactivez le compte de service pour vous assurer qu'il n'est pas nécessaire. Les comptes de service désactivés peuvent être réactivés s'ils sont toujours en cours d'utilisation.

Après avoir confirmé que le compte de service n'est pas nécessaire, vous pouvez supprimer le compte de service.

Recréer des comptes de service supprimés

Il est possible de supprimer un compte de service, puis de créer un nouveau compte de service portant le même nom.

Lorsque vous supprimez un compte de service, ses liaisons de rôle ne sont pas immédiatement supprimées. Au lieu de cela, les liaisons de rôles répertorient le compte de service avec le préfixe deleted:. Pour obtenir un exemple, consultez la section Stratégies avec des comptes principaux supprimés.

Si vous créez un compte de service portant le même nom qu'un compte de service récemment supprimé, les anciennes liaisons peuvent toujours exister. Cependant, elles ne s'appliqueront pas au nouveau compte de service, même si les deux comptes ont la même adresse e-mail. Ce comportement est dû au fait que les comptes de service reçoivent un ID unique dans Identity and Access Management (IAM) au moment de leur création. En interne, toutes les liaisons de rôles sont attribuées à l'aide de ces ID, et non de l'adresse e-mail du compte de service. Par conséquent, les liaisons de rôles qui existaient déjà pour un compte de service supprimé ne s'appliquent pas à un nouveau compte de service utilisant la même adresse e-mail.

De même, si vous rattachez un compte de service à une ressource, supprimez alors le compte de service, puis créez un compte de service portant le même nom. Le nouveau compte de service ne sera pas rattaché à la ressource.

Pour éviter ce comportement inattendu, pensez à utiliser un nouveau nom unique pour chaque compte de service. En outre, si vous supprimez accidentellement un compte de service, vous pouvez essayer d'annuler sa suppression au lieu de créer un autre compte.

Si vous ne pouvez pas annuler la suppression du compte de service d'origine et que vous devez créer un compte de service portant le même nom et disposant des mêmes rôles, vous devez attribuer les rôles au nouveau compte de service. Pour en savoir plus, consultez la section Stratégies avec des comptes principaux supprimés.

Si vous devez également rattacher le nouveau compte de service aux mêmes ressources que le compte de service d'origine, procédez de l'une des manières suivantes :

Étapes 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