Comprendre les comptes de service

Contexte

Un compte de service est un compte Google spécial destiné à représenter un utilisateur non humain qui doit s'authentifier et obtenir les autorisations permettant d'accéder aux données des API Google.

En règle générale, les comptes de service sont utilisés dans les situations suivantes :

  • L'exécution de charges de travail sur des machines virtuelles (VM).
  • L'exécution de charges de travail sur des postes de travail ou des centres de données sur site qui appellent des API Google.
  • L'exécution de charges de travail qui ne sont pas liées au cycle de vie d'un utilisateur humain.

Votre application revêt l'identité du compte de service pour appeler les API Google, afin que les utilisateurs ne soient pas directement impliqués.

Gérer les comptes de service

Une fois que vous décidez que vous avez besoin d'un compte de service, vous pouvez vous poser les questions suivantes pour comprendre comment vous allez utiliser le compte de service :

  • À quelles ressources le compte de service peut-il accéder ?
  • De quelles autorisations le compte de service a-t-il besoin ?
  • Où le code qui revêt l'identité du compte de service sera-t-il exécuté : sur Google Cloud Platform ou sur site ?

Utilisez l'organigramme suivant pour comprendre les réponses aux questions ci-dessus :

Organigramme du compte de service

Notez que les comptes de service peuvent être considérés à la fois comme une ressource et comme une identité.

Lorsque vous envisagez d'associer le compte de service à une identité, vous pouvez lui attribuer un rôle lui permettant d'accéder à une ressource (un projet, par exemple).

Lorsque vous souhaitez utiliser un compte de service en tant que ressource, vous pouvez attribuer à d'autres utilisateurs des rôles leur permettant d'accéder à ce compte de service ou de le gérer.

Attribuer des accès aux comptes de service

Autoriser l'accès à un compte de service pour accéder à une ressource revient à accorder l'accès à n'importe quelle autre identité. Par exemple, si vous utilisez une application s'exécutant sur Google Compute Engine et que vous souhaitez que l'application dispose uniquement d'un accès pour créer des objets dans Google Cloud Storage. Vous pouvez créer un compte de service pour l'application et lui attribuer le rôle Créateur des objets de l'espace de stockage. Le diagramme suivant illustre cet exemple :

Organigramme du compte de service

Découvrez comment attribuer des rôles à tous les types de membres, y compris aux comptes de service.

Garder une trace 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.

Supprimer et recréer des comptes de service

Il est possible de supprimer un compte de service, puis de créer un nouveau compte de service portant le même nom. Si vous réutilisez le nom d'un compte de service supprimé, cela peut entraîner un comportement inattendu.

Lorsque vous supprimez un compte de service, ses liaisons de rôle ne sont pas immédiatement supprimées. Si vous créez un nouveau 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 Cloud IAM lors de la création. En interne, toutes les liaisons de rôle 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ôle qui existaient déjà pour un compte de service supprimé ne s'appliquent pas à un nouveau compte de service utilisant la même adresse de messagerie.

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 parvenez 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, procédez comme suit :

  1. Créez le compte de service.
  2. Pour chaque ressource à laquelle le nouveau compte de service doit accéder, révoquez tous les rôles attribués au compte de service d'origine concernant cette ressource.

  3. Après avoir révoqué les rôles du compte de service d'origine, accordez les rôles au nouveau compte de service.

Autorisations pour les comptes de service

Cette section décrit les scénarios les plus courants concernant les autorisations accordées aux comptes de service ou aux comptes d'utilisateurs autorisés à emprunter l'identité des comptes de service :

Attribuer des autorisations minimales aux comptes de service

Comme pour tous les types de membres, vous ne devez accorder au compte de service que le nombre minimal d'autorisations requises pour atteindre son objectif. Découvrez comment attribuer des rôles à tous les types de membres, y compris aux comptes de service.

Lorsque vous accordez des autorisations aux utilisateurs pour accéder à un compte de service, gardez à l'esprit que l'utilisateur peut accéder à toutes les ressources pour lesquelles le compte de service dispose d'autorisations. Par conséquent, il est important de configurer les autorisations de vos comptes de service avec soin. Vous devez donc être strict sur les membres de votre équipe pouvant agir en tant que compte de service ou emprunter son identité.

Les utilisateurs disposant de rôles IAM pour mettre à jour les instances App Engine et Compute Engine (tels que celui de l'utilisateur à l'origine du déploiement App Engine ou de l'administrateur d'instances Compute) peuvent efficacement exécuter du code en tant que comptes de service utilisés pour exécuter ces instances, et accéder indirectement à toutes les ressources auxquelles les comptes de service ont accès. De même, l'accès SSH à une instance Compute Engine peut également permettre d'exécuter du code en tant qu'instance.

Autorisations de compte de service pour les scénarios courants

Les comptes de service peuvent être utilisés dans de nombreux scénarios différents, chacun d'entre eux nécessitant certaines autorisations. Cette section décrit les scénarios courants et les autorisations requises associées.

Démarrer des tâches de longue durée

Autorisations :

  • iam.serviceAccounts.actAs

Rôles :

  • roles/editor (Éditeur)
  • roles/iam.serviceAccountUser (Utilisateur du compte de service)

Un utilisateur (ou un service) peut associer un compte de service à un service de tâches de longue durée. Voici quelques exemples :

  • VM Compute Engine
  • Application App Engine
  • Fonction Cloud Functions
  • Tâche Dataflow

Dans ce scénario, l'utilisateur doit obtenir l'autorisation de déployer la tâche, qui varie selon le service, et l'autorisation iam.serviceAccounts.actAs, qui permet d'emprunter l'identité du compte de service. Notez que l'autorisation iam.serviceAccounts.actAs obtenue seule ne permet pas d'emprunter l'identité du compte de service.

Une fois que l'autorisation iam.serviceAccounts.actAs a été accordée sur le compte de service, il est possible de démarrer une tâche de longue durée qui s'exécute en tant que compte de service. Une fois que la tâche a démarré, cet utilisateur n'a plus besoin de conserver l'accès au compte de service. La tâche reste en cours d'exécution même si cet utilisateur perd l'accès. Le service de tâches continue d'utiliser ses propres autorisations sur le compte de service pour continuer à exécuter la tâche avec cette identité de compte de service.

Notez qu'il est parfois nécessaire de disposer de l'autorisation iam.serviceAccounts.actAs pour modifier une tâche de longue durée en cours d'exécution, telle que la configuration des métadonnées de l'instance sur une VM Compute Engine.

Pour plus d'informations sur ce flux, consultez la section Créer et activer des comptes de service pour les instances dans la documentation de Compute Engine.

Emprunter directement l'identité d'un compte de service

Autorisations :

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccounts.implicitDelegation

Rôles :

  • roles/iam.serviceAccountTokenCreator (Créateur de jetons du compte de service)

Une fois les autorisations requises accordées, un utilisateur (ou un service) peut directement emprunter ou revendiquer l'identité d'un compte de service selon plusieurs scénarios courants.

Tout d'abord, l'utilisateur peut obtenir des identifiants à court terme pour le compte de service en utilisant l'autorisation iam.serviceAccounts.getAccessToken et en appelant la méthode generateAccessToken(). En utilisant des identifiants à court terme, un utilisateur peut émettre des commandes vers Google Cloud et accéder à toutes les ressources auxquelles le compte de service a accès. Par exemple, ce flux permet à un utilisateur de se servir de l'indicateur gcloud --impersonate-service-account pour emprunter l'identité du compte de service sans utiliser de clé de compte de service externe téléchargée.

L'utilisateur peut également obtenir des artefacts signés par la clé privée gérée par Google associée au compte de service en utilisant l'autorisation iam.serviceAccounts.signBlob et en appelant la méthode signBlob() ou la méthode signJwt(). La clé privée gérée par Google est toujours conservée à titre de caution et n'est jamais directement exposée. signBlob() autorise la signature de charges utiles arbitraires (telles que des URL signées Cloud Storage), tandis que signJwt() ne permet que la signature de jetons JWT correctement formés.

Enfin, l'utilisateur peut emprunter ou revendiquer l'identité du compte de service sans avoir à récupérer les identifiants de celui-ci. Il s'agit d'un cas d'utilisation avancé, qui n'est compatible qu'avec l'accès automatisé à l'aide de la méthode generateAccessToken(). Dans les scénarios comportant au moins trois comptes de service, à savoir A, B, et C : le compte de service A peut obtenir un jeton d'accès pour le compte de service C si le compte de service A dispose de l'autorisation iam.serviceAccounts.implicitDelegation sur le compte de service B et si le compte de service B dispose de l'autorisation iam.serviceAccounts.getAccessToken sur le compte de service C.

Générer des jetons d'identification OIDC (OpenID Connect)

Autorisations :

  • iam.serviceAccounts.getOpenIdToken

Rôles :

  • roles/iam.serviceAccountTokenCreator (Créateur de jetons du compte de service)

L'autorisation iam.serviceAccounts.getOpenIdToken permet à un utilisateur (ou à un service) de générer un jeton JWT compatible avec OIDC (OpenID Connect) signé par le fournisseur OIDC de Google (accounts.google.com), qui représente l'identité du compte de service.

Ces jetons ne sont pas directement acceptés par la plupart des API Google tant que votre organisation ne déploie pas de systèmes de fédération d'identité supplémentaires pour accorder l'accès à Google. Il existe quelques exceptions, comme Identity-Aware Proxy, qui permet l'accès OIDC aux applications exécutées par les utilisateurs.

Générer des clés privées externes

Autorisations :

  • iam.serviceAccountKeys.create

Rôles :

  • roles/editor (Éditeur)
  • roles/iam.serviceAccountAdmin (Administrateur de compte de service)

Un utilisateur (ou un service) peut générer un matériel de clé privée externe (RSA) qui peut servir à s'authentifier directement auprès de Google en tant que compte de service. Ce matériel de clé peut ensuite être utilisé avec les bibliothèques ADC (Identifiants par défaut de l'application) ou avec la commande gcloud auth activate-service-account. Toute personne ayant accès au matériel de clé peut alors accéder à toutes les ressources auxquelles le compte de service a lui-même accès. Ce type de matériel de clé privée doit être traité avec beaucoup de précautions et doit être considéré comme moins sûr à mesure que sa durée de vie augmente. Par conséquent, la rotation des matériels de clé privée est essentielle pour garantir une sécurité optimale.

Gérer des clés du compte de service

Il existe deux types de clés de compte de service :

  • Les clés gérées par GCP. Ces clés sont utilisées par les services Cloud Platform tels que App Engine et Compute Engine. Vous ne pouvez pas les télécharger. Elles sont alternées automatiquement et utilisées pour la signature pendant deux semaines maximum. Le processus de rotation est probabiliste. L'utilisation de la nouvelle clé augmentera et diminuera progressivement au cours de la durée de vie de la clé. Nous vous recommandons de mettre en cache l'ensemble de clés publiques d'un compte de service pendant au plus 24 heures afin de vous assurer que vous avez toujours accès à l'ensemble de clés actuel.

  • Les clés gérées par l'utilisateur. Ces clés sont créées, téléchargées et gérées par les utilisateurs. Une fois que vous les avez supprimées du compte de service, vous ne pouvez pas les utiliser pour vous authentifier.

Pour les clés gérées par l'utilisateur, vous devez vous assurer que vous avez mis en place des processus pour répondre aux exigences de gestion des clés telles que :

  • Le stockage des clés
  • La distribution des clés
  • La révocation des clés
  • La rotation des clés
  • La protection des clés contre les utilisateurs non autorisés
  • La récupération des clés

Toute personne ayant accès à une clé privée valide pour un compte de service peut accéder aux ressources via le compte de service. Notez que le cycle de vie de l'accès de la clé au compte de service (et par conséquent, aux données auxquelles le compte de service a accès) est indépendant du cycle de vie de l'utilisateur ayant téléchargé la clé.

Découragez toujours les développeurs d'enregistrer les clés dans le code source ou de les laisser dans le répertoire Téléchargements de leur poste de travail.

Pour améliorer la sécurité des clés, suivez les instructions ci-dessous :

Utiliser des comptes de service avec Compute Engine

Vous devez exécuter les instances de Compute Engine en tant que comptes de service pour avoir accès à d'autres ressources Cloud Platform. Pour vérifier que vos instances Compute Engine sont sécurisées, tenez compte des points suivants :

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

  • Vous pouvez attribuer des rôles IAM aux comptes de service pour définir ce à quoi ils peuvent accéder. Dans de nombreux cas, vous n’avez plus besoin de vous fier aux champs d'application. Cela vous donne l'avantage de pouvoir modifier les autorisations du compte de service d'une VM sans recréer l'instance.

  • Étant donné que les instances dépendent de leurs comptes de service pour accéder aux ressources de Cloud Platform, évitez de supprimer les comptes de service tant qu'ils sont encore utilisés par des instances en cours d'exécution. Si vous supprimez les comptes de service, les opérations des instances peuvent commencer à échouer.

Bonnes pratiques

  • Indiquez les utilisateurs autorisés à agir en tant que comptes de service. Les membres qui sont des utilisateurs du compte de service pour un compte de service peuvent exploiter indirectement toutes les ressources accessibles par le compte de service. Par conséquent, soyez prudent lorsque vous attribuez le rôle d'utilisateur du compte de service à un utilisateur.

  • Vous devez uniquement attribuer au compte de service l'ensemble minimal d'autorisations requis pour atteindre son objectif. Découvrez comment attribuer des rôles à tous les types de membres, y compris aux comptes de service.

  • Créez des comptes de service pour chaque service avec uniquement les autorisations requises pour ce service.

  • Utilisez le nom à afficher d'un compte de service pour effectuer un suivi des comptes de service. Lorsque vous créez un compte de service, utilisez sa finalité pour enseigner son nom à afficher.

  • Définissez une convention de dénomination pour vos comptes de service.

  • Implémentez des processus pour automatiser la rotation des clés de compte de service gérées par l'utilisateur.

  • Tirez parti de l'API du compte de service IAM pour mettre en œuvre la rotation de clé.

  • Effectuez un audit des clés et des comptes de service à l'aide de la méthode serviceAccount.keys.list() ou de la page Visionneuse de journaux de la console.

  • Ne supprimez pas les comptes de service en cours d'utilisation lors de l'exécution d'instances sur App Engine ou Compute Engine. Sinon, ces applications perdront l'accès au compte de service.