Comptes de service

Cette page décrit les comptes de service et leurs autorisations, qui peuvent être limitées par les niveaux d'accès, qui s'appliquent aux instances de VM et par les rôles IAM (Cloud Identity and Access Management), qui s'appliquent aux comptes de service. 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.

Un compte de service est un compte spécial qui peut être utilisé par des services et des applications exécutés sur votre instance Compute Engine pour interagir avec d'autres API Google Cloud Platform. Les applications peuvent utiliser les identifiants de compte de service pour obtenir les autorisations d'accès à un ensemble d'API et effectuer des actions dans la limite des autorisations accordées au compte de service et à l'instance de machine virtuelle. 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.

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

Un compte de service est une identité qu'une instance ou une application peut utiliser pour exécuter des requêtes API en votre nom.

Cette identité permet d'assurer l'identification des applications exécutées sur vos instances de machine virtuelle auprès d'autres services Google Cloud Platform. Par exemple, si vous écrivez 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 un compte de service et l'autoriser à accéder à l'API Cloud Storage. Modifiez ensuite votre application pour qu'elle transmette les identifiants de ce compte de service à l'API Cloud Storage. Votre application s'authentifie de manière transparente auprès de l'API sans avoir à intégrer de clés secrètes ou d'identifiants utilisateur sur votre instance, sur votre image ou dans le code de votre application.

Si vos comptes de service disposent des autorisations IAM nécessaires, ils peuvent créer et gérer des instances et d'autres ressources. Les comptes de service ne peuvent modifier ou supprimer des ressources que si vous leur accordez les autorisations IAM nécessaires au niveau du projet ou de la ressource. Vous pouvez également modifier le compte de service associé à une instance.

Une instance ne peut posséder qu'un seul compte de service, et celui-ci doit avoir été créé dans le même projet que l'instance.

Deux types de comptes de service sont disponibles pour les instances Compute Engine :

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

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 de Cloud Identity and Access Management. 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 où le compte de service est activé 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 disposent du compte de service Compute Engine par défaut, identifiable par 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 Cloud IAM d'éditeur de projet, mais vous pouvez modifier les rôles associés à ce compte afin de restreindre de manière fiable son accès aux API Google.

Vous avez la possibilité de supprimer ce compte de service de votre projet, mais cela 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 automatiquement créé par le projet de la console Google Cloud Platform. Il possède un nom et une adresse e-mail qui ont été générés automatiquement.
  • Il est ajouté automatiquement à votre projet avec le rôle Cloud IAM d'éditeur de projet.
  • Il est activé par défaut sur toutes les instances créées par l'outil de ligne de commande gcloud et la console GCP. Vous pouvez remplacer ce paramètre en spécifiant un autre compte de service lors de la création de l'instance ou en désactivant explicitement les comptes de service pour l'instance.

Associer un compte de service à une instance

Lorsque vous créez une instance à l'aide de l'outil de ligne de commande gcloud ou de la console Google Cloud Platform, vous pouvez spécifier quel compte de service doit être utilisé par l'instance lorsqu'elle effectue des appels auprès des API GCP. L'instance 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

Les niveaux d'accès définissent les champs d'application OAuth par défaut pour les requêtes effectuées via les bibliothèques clientes et l'outil gcloud. Par conséquent, ils limitent potentiellement 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. Par conséquent, il est recommandé de définir l'intégralité du niveau d'accès cloud-platform sur l'instance, puis de restreindre de manière sécurisée les accès au compte de service en lui attribuant des rôles IAM. Consultez la section Autorisations de compte de service pour en savoir plus.

Lorsque vous créez une instance en envoyant directement une requête à l'API sans utiliser l'outil de ligne de commande gcloud ni la console Google Cloud Platform, le compte de service par défaut n'est pas activé avec l'instance. En revanche, vous pouvez toujours activer ce dernier en le spécifiant explicitement dans la charge utile de la requête.

Comptes de service gérés par Google

Ces comptes de service sont créés et gérés par Google, et attribués 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 Platform.

Compte 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 compte 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 la console GCP. Par défaut, ce compte reçoit automatiquement le rôle d'éditeur de projet. Il est répertorié dans la section IAM de la console GCP. 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.

Compte de service Compute Engine System

Tous les projets pour lesquels l'API Compute Engine est activée disposent d'un compte de service Compute Engine System qui peut être identifié à l'aide 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. Il est répertorié dans les sections "Comptes de service" et "IAM" de la console GCP. Par défaut, ce compte 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 ne devez pas modifier les rôles de ce compte de service.

Autorisations de compte de service

Lorsque vous configurez une instance pour qu'elle s'exécute en tant que compte de service, vous déterminez le niveau d'accès au compte de service par le biais des rôles IAM que vous accordez à ce compte. Si le compte de service ne dispose d'aucun rôle IAM, aucune méthode d'API ne peut être exécutée par 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 l'outil gcloud et les bibliothèques clientes de 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 à restreindre de manière sécurisée 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 lors de l'authentification via OAuth.

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

Vous avez le choix entre de nombreux niveaux d'accès, mais vous pouvez également définir le niveau d'accès cloud-platform, qui est un champ d'application OAuth pour tous les services Google Cloud Platform, puis restreindre de manière sécurisée les accès au compte de service en lui attribuant des rôles IAM.

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

Par exemple, 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 IAM. Ce compte ne peut effectuer aucune action en dehors de ces rôles, malgré le niveau d'accès Google Cloud Platform.

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

En règle générale, la documentation relative à 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.

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.

Les rôles IAM sont spécifiques au compte. Cela signifie qu'une fois qu'un rôle IAM a été attribué à un compte de service, toute instance s'exécutant sous l'identité de ce compte de service peut utiliser ce rôle. Gardez également à l'esprit les points suivants :

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

    Si aucun rôle IAM n'est prédéfini pour le niveau d'accès souhaité, vous pouvez attribuer l'un des rôles primitifs, tel que celui d'éditeur de projet, ou 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 IAM 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 l'outil gcloud 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 ne constituent pas un mécanisme de sécurité. À la place, ils définissent les champs d'application OAuth par défaut utilisés dans les requêtes provenant de l'outil gcloud ou des bibliothèques clientes. Notez qu'ils n'ont aucun effet lors de l'exécution de requêtes non authentifiées via OAuth, telles que gRPC ou les API SignBlob.

Vous devez définir des niveaux d'accès lorsque vous configurez une instance pour qu'elle s'exécute en tant que compte de service.

Il est recommandé de définir l'intégralité du niveau d'accès cloud-platform sur l'instance, puis de restreindre de manière sécurisée les accès du compte de service aux API à l'aide de rôles Cloud IAM.

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.

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.

Exemples de niveaux d'accès :

  • https://www.googleapis.com/auth/cloud-platform. Accès complet à toutes les ressources GCP.
  • 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

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine