Service Accounts

Cette page décrit le fonctionnement des comptes de service avec Compute Engine.

Pour obtenir des informations détaillées sur le rattachement d'un compte de service à une instance de machine virtuelle (VM), consultez l'un des documents suivants :

Pour en savoir plus sur les bonnes pratiques à suivre pour créer et gérer des comptes de service, consultez la documentation Bonnes pratiques d'utilisation des comptes de service.

Faites l'essai

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

Profiter d'un essai gratuit de Compute Engine

Qu'est-ce qu'un compte de service ?

Un compte de service est un type particulier de compte utilisé par une application ou une charge de travail de calcul, et non par une personne. Les comptes de service sont gérés par Identity and Access Management (IAM).

Tenez compte des points suivants lorsque vous utilisez des comptes de service avec vos VM :

  • Vous pouvez associer le même compte de service à plusieurs VM, mais une même VM ne peut être associée qu'à un seul compte de service.
  • Si vous associez le même compte de service à plusieurs VM, toute modification ultérieure apportée au compte de service affecte toutes les VM utilisant le compte de service. Cela inclut toutes les modifications apportées aux rôles IAM qui sont accordés au compte de service. Par exemple, si vous supprimez un rôle, toutes les VM utilisant le compte de service perdent les autorisations accordées par ce rôle.

Utilisation des comptes de service par Compute Engine

Compute Engine utilise deux types de comptes de service :

Un compte de service géré par l'utilisateur peut être associé à une instance Compute Engine pour fournir des identifiants aux applications s'exécutant sur l'instance. Ces identifiants sont utilisés par l'application pour l'authentification auprès des API Google Cloud et pour autoriser l'accès aux ressources Google Cloud. Seuls les comptes de service gérés par l'utilisateur peuvent être associés à une instance, et une instance ne peut être associée qu'à un seul compte de service. Vous pouvez définir ou modifier le compte de service associé à une instance au moment de sa création ou ultérieurement.

Les agents de service permettent à l'instance d'accéder aux processus internes en votre nom.

De plus, vous pouvez créer des règles de pare-feu pour autoriser ou refuser le trafic vers et depuis des instances en fonction du compte de service que vous associez à chaque instance.

Comment l'autorisation est-elle déterminée ?

L'autorisation fournie aux applications hébergées sur une instance Compute Engine est limitée par deux configurations distinctes : les rôles accordés au compte de service associé et les niveaux d'accès que vous définissez sur l'instance. Ces deux configurations doivent autoriser l'accès pour que l'application en cours d'exécution sur l'instance puisse accéder à une ressource.

Si vous disposez d'une application qui lit et écrit des fichiers dans Cloud Storage, elle doit commencer par s'authentifier auprès de l'API Cloud Storage. Vous pouvez créer une instance avec le niveau d'accès cloud-platform et lui associer un compte de service. Vous pouvez ensuite attribuer des rôles IAM (Identity and Access Management) au compte de service pour permettre à votre application d'accéder aux ressources appropriées. Votre application s'authentifie auprès de l'API Cloud Storage à l'aide des identifiants du compte de service. Vous n'avez pas à intégrer de clés secrètes ou d'identifiants utilisateur à votre instance, à votre image ou au code de votre application. Votre application utilise également l'autorisation fournie par les rôles IAM au compte de service pour accéder aux ressources. Pour en savoir plus sur les autorisations, consultez la section Autorisation sur cette page.

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

Les comptes de service gérés par l'utilisateur incluent les nouveaux comptes de service que vous créez explicitement et le compte de service Compute Engine par défaut.

Nouveaux comptes de service

Vous pouvez créer et gérer vos propres comptes de service à l'aide d'IAM. Après avoir créé un compte, attribuez-lui des rôles IAM et configurez les instances à exécuter en tant que compte de service. Les applications exécutées sur des instances à l'aide du compte de service associé peuvent utiliser les identifiants du compte pour envoyer des requêtes à d'autres API Google.

Pour créer et configurer un compte de service, consultez la page Créer une VM qui utilise un compte de service géré par l'utilisateur.

Compte de service Compute Engine par défaut

Les nouveaux projets pour lesquels l'API Compute Engine est activée disposent d'un compte de service Compute Engine par défaut, doté de l'adresse e-mail suivante :

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Le compte de service Compute Engine par défaut possède les attributs suivants :

  • Il est créé automatiquement avec un nom et une adresse e-mail générés automatiquement, et ajouté à votre projet lorsque vous activez l'API Compute Engine. Vous bénéficiez d'un contrôle total sur le compte.
  • Il est associé par défaut à toutes les VM que vous avez créées à l'aide de Google Cloud CLI ou de la console Google Cloud. Vous pouvez ignorer ce comportement en spécifiant un autre compte de service lors de la création de la VM ou en indiquant explicitement qu'aucun compte de service n'est associé à la VM.

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

Vous avez la possibilité de désactiver ce compte de service ou de le supprimer de votre projet, mais cette opération peut entraîner l'échec des applications qui dépendent des identifiants du compte de service. Si vous supprimez accidentellement le compte de service Compute Engine par défaut, vous pouvez essayer de le récupérer dans un délai de 30 jours. Pour en savoir plus, consultez Supprimer et restaurer des comptes de service.

Si le compte de service Compute Engine par défaut a été supprimé il y a plus de 30 jours, vous pouvez essayer de le restaurer en suivant la procédure décrite dans Résoudre les problèmes liés aux comptes de service par défaut.

Agents de service

Les agents de service sont créés et gérés par Google Cloud et attribués automatiquement à votre projet. Ces comptes représentent différents services Google Cloud, et chaque compte dispose généralement d'un certain niveau d'accès à vos ressources Google Cloud.

Vous ne pouvez pas associer d'agents de service à une instance Compute Engine.

Agent de service des API Google

Hormis le compte de service par défaut, tous les projets compatibles avec Compute Engine sont dotés d'un agent de service des API Google. Il peut être identifié à l'aide de cette adresse e-mail :

PROJECT_NUMBER@cloudservices.gserviceaccount.com

Ce agent de service est spécifiquement conçu pour exécuter les processus Google internes en votre nom. Cet agent de service appartient à Google et ne figure pas dans la section Comptes de service de la console Google Cloud. Par défaut, le rôle d'éditeur de projet est automatiquement attribué à cet agent de service pour le projet. Et l'agent de service apparaît dans la section IAM de la console Google Cloud. Cet agent de service n'est supprimé que lors de la suppression du projet. En revanche, vous pouvez modifier les rôles attribués à ce compte, y compris révoquer tous les accès à votre projet.

Certaines ressources dépendent des autorisations de modification accordées par défaut à cet agent de service. Par exemple, les groupes d'instances gérés et l'autoscaling utilisent les identifiants de cet agent de service pour créer, supprimer et gérer des instances. Si vous révoquez des autorisations pour cet agent de service ou si vous modifiez les autorisations de manière à ne pas autoriser la création d'instances, les groupes d'instances gérés et l'autoscaling cesseront de fonctionner.

C'est pourquoi vous ne devez pas modifier les rôles de cet agent de service, sauf si une recommandation de rôle vous suggère explicitement de les modifier.

Agent de service Compute Engine

Tous les projets pour lesquels l'API Compute Engine est activée disposent d'un agent de service Compute Engine, dont l'adresse e-mail est la suivante :

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

Cet agent de service est conçu spécifiquement pour permettre à Compute Engine de remplir ses fonctions de service sur votre projet. Il repose sur la stratégie IAM relative aux agents de service attribuée à votre projet Google Cloud. Il s'agit également de l'agent de service permettant à Compute Engine d'accéder au compte de service géré par l'utilisateur sur les instances de VM. Ce compte appartient à Google, mais il est spécifique à votre projet. Cet agent de service n'apparaît pas sur la page IAM de la console, sauf si vous sélectionnez Inclure les attributions de rôles fournies par Google. Par défaut, cet agent de service se voit automatiquement attribuer le rôle compute.serviceAgent sur votre projet.

Cet agent de service n'est supprimé que lorsque vous supprimez votre projet. Vous pouvez modifier les rôles attribués à cet agent de service et révoquer tous les accès à votre projet depuis cet agent. La révocation ou la modification des autorisations de cet agent de service empêche Compute Engine d'accéder aux identités de vos comptes de service sur vos VM et peut entraîner des pannes de logiciels exécutés sur vos VM.

C'est pourquoi vous devez éviter autant que possible de modifier les rôles de cet agent de service.

Associer un compte de service à une instance

Pour éviter de fournir à une application des autorisations en excès, nous vous recommandons de créer un compte de service géré par l'utilisateur, de ne lui attribuer que les rôles dont votre application a besoin pour fonctionner correctement et de l'associer à votre instance Compute Engine. Votre code peut ensuite utiliser les identifiants par défaut de l'application pour s'authentifier avec les identifiants fournis par le compte de service.

Vous pouvez associer un compte de service à une instance Compute Engine lors de la création de celle-ci, ou ultérieurement. Un seul compte de service peut être associé à une instance à la fois. Si vous associez un compte de service à une instance qui est déjà associée à un compte de service, le compte de service précédent n'est plus utilisé par cette instance.

Lorsque vous associez un compte de service à une instance Compute Engine, vous devez également vous assurer que les champs d'application définis sur l'instance sont corrects. Sinon, votre application risque de ne pas pouvoir accéder à toutes les API dont elle a besoin. Pour plus d'informations, consultez la section Niveaux d'accès sur cette page.

Pour obtenir des informations détaillées sur le rattachement d'un compte de service à une instance Compute Engine, consultez l'un des documents suivants :

Autorisation

Lorsque vous configurez une instance à exécuter en tant que compte de service, vous déterminez le niveau d'accès du compte de service par les rôles IAM que vous accordez au compte de service. Si le compte de service ne dispose d'aucun rôle IAM, aucune ressource n'est accessible via le compte de service sur cette instance.

De plus, les niveaux d'accès d'une instance déterminent les champs d'application OAuth par défaut pour les requêtes effectuées via gcloud CLI et les bibliothèques clientes sur l'instance. Par conséquent, les niveaux d'accès peuvent limiter davantage l'accès aux méthodes API lors de l'authentification via OAuth. En revanche, ils ne s'appliquent pas aux autres protocoles d'authentification, tels que gRPC.

Une bonne pratique consiste à définir l'intégralité du niveau d'accès cloud-platform sur l'instance, puis à contrôler les accès du compte de service à l'aide de rôles IAM.

En bref :

  • IAM restreint l'accès aux API en fonction des rôles IAM attribués au compte de service.
  • Les niveaux d'accès peuvent limiter davantage l'accès aux méthodes API.

Les niveaux d'accès et les rôles IAM sont décrits en détail dans les sections suivantes.

Rôles IAM

Vous devez attribuer des rôles IAM appropriés à un compte de service pour lui permettre d'accéder aux méthodes d'API pertinentes.

Par exemple, vous pouvez attribuer des rôles IAM à un compte de service pour gérer des objets et/ou des buckets Cloud Storage, ce qui restreint le compte aux autorisations accordées par ces rôles.

Lorsque vous attribuez un rôle IAM à un compte de service, l'autorisation est accordée par ce rôle à toute application s'exécutant sur une instance à laquelle ce compte de service est associé.

Informations à retenir :

  • Certains rôles IAM sont en version bêta.

    Si aucun rôle n'est prédéfini pour le niveau d'accès souhaité, vous pouvez créer et attribuer des rôles personnalisés.

  • Vous devez définir des niveaux d'accès sur l'instance pour autoriser l'accès.

    Alors que le niveau d'accès d'un compte de service est déterminé par les rôles qui lui sont attribués, les niveaux d'accès d'une instance déterminent les champs d'application OAuth par défaut pour les requêtes effectuées via gcloud CLI et les bibliothèques clientes sur l'instance. Par conséquent, les niveaux d'accès peuvent limiter davantage l'accès aux méthodes d'API lors de l'authentification via OAuth.

Niveaux d'accès

Les niveaux d'accès représentent l'ancienne méthode de spécification des autorisations associées à votre VM. Ils définissent les champs d'application OAuth par défaut utilisés dans les requêtes provenant de gcloud CLI ou des bibliothèques clientes Les niveaux d'accès ne s'appliquent pas aux appels effectués à l'aide de gRPC.

Les niveaux d'accès s'appliquent par VM et ne sont conservés que pendant la durée de vie de la VM. Vous pouvez définir des niveaux d'accès lors de la création d'une VM ou mettre à jour le niveau d'accès sur une VM existante.

En règle générale, la documentation propre à chaque méthode API présente la liste des niveaux d'accès requis pour cette méthode. Par exemple, la méthode instances.insert fournit une liste de niveaux d'accès valides dans sa section Autorisation.

Les niveaux d'accès ne fonctionnent que si vous avez activé l'API associée sur le projet auquel appartient le compte de service. Par exemple, accorder un niveau d'accès à Google Cloud Storage sur une instance de machine virtuelle permet à l'instance d'appeler l'API Cloud Storage uniquement si vous avez activé l'API Cloud Storage sur le projet.

Niveaux d'accès par défaut

Lorsque vous créez une instance Compute Engine, elle est automatiquement configurée avec les niveaux d'accès suivants :

  • Accès en lecture seule à Cloud Storage :
    https://www.googleapis.com/auth/devstorage.read_only
  • Accès en écriture pour consigner des journaux Compute Engine :
    https://www.googleapis.com/auth/logging.write
  • Accès en écriture pour publier des données de métriques dans vos projets Google Cloud :
    https://www.googleapis.com/auth/monitoring.write
  • Accès en lecture seule aux fonctionnalités Service Management requises pour Google Cloud Endpoints(alpha) :
    https://www.googleapis.com/auth/service.management.readonly
  • Accès en lecture/écriture aux fonctionnalités Service Control requises pour Google Cloud Endpoints(alpha) :
    https://www.googleapis.com/auth/servicecontrol
  • Accès en écriture à Cloud Trace permettant à une application exécutée sur une VM d'écrire des données de trace dans un projet :
    https://www.googleapis.com/auth/trace.append

Bonnes pratiques concernant les niveaux d'accès

Vous avez le choix entre de nombreux niveaux d'accès, mais il est recommandé de définir le niveau d'accès cloud-platform, qui est un champ d'application OAuth pour les services Google Cloud, puis de contrôler l'accès du compte de service en lui attribuant des rôles IAM.

https://www.googleapis.com/auth/cloud-platform

Exemples de niveaux d'accès

Conformément aux bonnes pratiques sur les champs d'application, si vous avez activé le niveau d'accès cloud-platform sur une instance, puis que vous avez accordé les rôles IAM prédéfinis suivants :

  • roles/compute.instanceAdmin.v1
  • roles/storage.objectViewer
  • roles/compute.networkAdmin

Le compte de service ne dispose ensuite que des autorisations incluses dans ces trois rôles. Les applications qui empruntent l'identité de ce compte de service ne peuvent effectuer aucune action en dehors de ces rôles, malgré le niveau d'accès Google Cloud.

Par ailleurs, si vous définissez un niveau d'accès plus restrictif pour l'instance, comme le niveau Lecture seule Cloud Storage (https://www.googleapis.com/auth/devstorage.read_only), puis que vous attribuez au compte de service le rôle d'administrateur roles/storage.objectAdmin, alors, par défaut, les requêtes provenant de gcloud CLI et des bibliothèques clientes sont dans l'impossibilité de gérer les objets Cloud Storage à partir de cette instance, bien que vous ayez attribué au compte de service le rôle roles/storage.ObjectAdmin. En effet, le niveau d'accès en lecture seule Cloud Storage n'autorise pas l'instance à manipuler les données Cloud Storage.

Voici quelques exemples de niveaux d'accès :

  • https://www.googleapis.com/auth/cloud-platform. Affichage et gestion des données sur les services Google Cloud dans le projet Google Cloud spécifié.
  • https://www.googleapis.com/auth/compute : accès aux méthodes Compute Engine avec contrôle total.
  • https://www.googleapis.com/auth/compute.readonly. Accès en lecture seule aux méthodes Compute Engine.
  • https://www.googleapis.com/auth/devstorage.read_only. Accès en lecture seule à Cloud Storage.
  • https://www.googleapis.com/auth/logging.write. Accès en écriture aux journaux Compute Engine.

Étapes suivantes