Comptes de service

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.

Les documents suivants décrivent les bonnes pratiques à suivre pour utiliser et sécuriser les 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 offerts 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 la 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 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 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 champ d'application 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 sans avoir à 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 sur le 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 avec le 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, doté de l'adresse e-mail suivante :

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Google crée le compte de service Compute Engine par défaut et l'ajoute automatiquement à votre projet. Vous bénéficiez néanmoins d'un contrôle total sur votre compte.

Le compte de service Compute Engine par défaut est créé avec le rôle IAM de base Éditeur. Toutefois, vous pouvez modifier les rôles de votre compte de service pour contrôler son accès aux API Google.

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 la page Créer et gérer des comptes de service.

En résumé, les caractéristiques du compte de service Compute Engine par défaut sont les suivantes :

  • 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.
  • Le rôle IAM de base Éditeur est attribué automatiquement si vous n'avez pas désactivé ce comportement.
  • Il est associé par défaut à toutes les instances créées par Google Cloud CLI et Cloud Console. Vous pouvez ignorer ce comportement en spécifiant un autre compte de service lors de la création de l'instance ou en indiquant explicitement qu'aucun compte de service n'est associé à l'instance.

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 l'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 Cloud Console. Par défaut, ce compte reçoit automatiquement le rôle d'éditeur de projet. Il est listé dans la section IAM de Cloud Console. 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 pour le 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 doté de l'adresse e-mail 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 permettant à Compute Engine d'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 est masqué à partir de 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.

En effet, 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 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 la section Créer et activer des comptes de service pour les instances.

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 d'API lors de l'authentification via OAuth. Toutefois, 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 au 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 d'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 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 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 d'API répertorie les 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
  • L'accès en écriture à Cloud Trace permet à 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 sur 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

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 à l'instance, comme le niveau de lecture seule Cloud Storage (https://www.googleapis.com/auth/devstorage.read_only), puis 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, même si vous avez 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 du 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.

Étape suivante