Service Accounts


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

Pour savoir comment créer et utiliser des comptes de service, consultez la documentation Créer et activer des comptes de service pour les instances.

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

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.

L'instance utilise les comptes de service gérés par Google pour 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 votre application doit lire et écrire 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 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 pour qu'elles s'exécutent via ce 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 un compte de service et le configurer, consultez la documentation Créer et activer des comptes de service pour les instances.

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, dont l'adresse e-mail est la 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.
  • Le rôle IAM de base Éditeur lui est attribué automatiquement si vous n'avez pas désactivé ce comportement. Vous pouvez modifier les rôles de votre compte de service pour contrôler son accès aux API Google.
  • 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.

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 plus d'informations, consultez Supprimer et restaurer des comptes de service.

Comptes de service gérés par Google

Ces comptes de service (parfois appelés agents de service) sont créés et gérés par Google et attribué automatiquement à votre projet. Ces comptes représentent différents services Google, et chacun d'entre eux dispose d'un certain niveau d'accès à votre projet Google Cloud.

Vous ne pouvez pas associer de comptes de service gérés par Google à 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 compte de service est spécifiquement conçu pour exécuter les processus Google internes en votre nom. Le compte appartient à Google et ne figure pas dans la section Comptes de service de la console Google Cloud. Par défaut, ce compte reçoit automatiquement le rôle d'éditeur de projet. Il apparaît dans la section IAM de la console Google Cloud. Ce compte de service est uniquement supprimé lorsque vous supprimez le 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 de ce compte de service et des autorisations de modification accordées par défaut au compte de service. Par exemple, les groupes d'instances gérés et l'autoscaling utilisent les identifiants de ce compte pour créer, supprimer et gérer des instances. Si vous révoquez des autorisations accordées au compte 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 ce compte 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

Ce compte 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 du compte de service qu'utilise Compute Engine pour accéder au compte de service détenu par le client sur les instances de VM. Ce compte appartient à Google, mais il est spécifique à votre projet. Ce compte 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, il reçoit automatiquement le rôle compute.serviceAgent pour votre projet.

Ce compte de service n'est supprimé que lorsque vous supprimez votre projet. Vous pouvez modifier les rôles attribués à ce compte et révoquer tous les accès à votre projet depuis le compte. La révocation ou la modification des autorisations de ce compte 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 ce compte 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 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 lorsque vous la créez, 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 niveaux d'accès 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 Créer et activer des comptes de service pour les instances.

Autorisation

Lorsque vous configurez une instance pour l'exécuter via un 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 ci-dessous.

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 API nécessaires.

Par exemple, vous pouvez attribuer des rôles IAM à un compte de service pour qu'il gère des objets et/ou des buckets Cloud Storage. Le compte est alors limité aux autorisations accordées par ces rôles.

Lorsque vous attribuez un rôle IAM à un compte de service, les autorisations que confère ce rôle sont accordées à 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 prédéfini n'existe 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 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 instance. 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 instance. Les niveaux d'accès, définis lors de la création d'une instance, sont exploitables uniquement pendant la durée de vie de cette instance.

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 ne permet à l'instance d'appeler l'API Cloud Storage que 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 la plupart des 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

Si conformément aux bonnes pratiques, vous avez activé le niveau d'accès cloud-platform sur une instance, puis 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 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 la plupart des 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