Contexte

Un compte de service est un type spécial de compte Google destiné à représenter un utilisateur non humain qui doit s’authentifier et être autorisé à accéder aux données dans les API Google.

Typiquement, les comptes de service sont utilisés dans des scénarios tels que :

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

Votre applicationassume l’identité du compte de service pour appeler les API Google,de sorte que les utilisateurs ne sont pas directement impliqués.

Gestion des 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 sont les ressources auxquelles le compte de service peut accéder ?
• Quelles sont les permissions dont le compte de service a besoin ?
• Où le code qui assume l’identité du compte de service s’exécutera-t-il – sur Google Cloud ou sur site ?

Utilisez l’organigramme suivant pour déterminer les réponses aux questions ci-dessus :

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

Lorsque vous pensez au compte de service en tant qu’identité, vous pouvez accorder un rôle à un compte de service, lui permettant d’accéder à une ressource (comme un projet).

Lorsque vous pensez à un compte de service en tant que ressource, vous pouvez accorder des rôles à d’autres utilisateurs pour accéder à ce compte de service ou le gérer.

Accorder l’accès aux comptes de service

Accorder l’accès à un compte de service pour accéder à une ressource est similaire à accorder l’accès à toute autre identité. Par exemple, si vous avez une application exécutée surCompute Engine et que vous voulez que l’application ait uniquement accès à la création d’objets dans Cloud Storage. Vous pouvez créer un compte de service pour l’application et lui accorder le rôle de créateur d’objets de stockage.Le diagramme suivant illustre cet exemple:

Learn aboutAttribution de rôles à tous les types de membres,y compris les comptes de service.

Garder la trace des comptes de service

Au fil du temps, alors que vous créez de plus en plus de comptes de service, vous pourriez perdre la trace de quel compte de service est utilisé à quelle fin.

Le nom d’affichage d’un compte de service est un bon moyen de capturer des informations supplémentaires sur le compte de service, comme l’objectif du compte de service ou une personne de contact pour le compte. Pour les nouveaux comptes de service, vous pouvezpopuler le nom d’affichage lors de la création du compte de service. Pour les comptes de service existants, utilisez la méthode serviceAccounts.update() pour modifier le nom d’affichage.

Identification des comptes de service inutilisés

Les comptes de service inutilisés créent un risque de sécurité inutile, nous recommandons donc de désactiver les comptes de service inutilisés, puis de supprimer les comptes de service lorsque vous êtes sûr de ne plus en avoir besoin. Vous pouvez utiliser les méthodes suivantes pour identifier les comptes de service inutilisés :

• Les aperçus de comptes de service vous indiquent quels comptes de service dansvotre projet n’ont pas été authentifiés au cours des 90 derniers jours.
• Les mesures d’utilisation des comptes de service vous permettent de vérifier quand un compte de service a été utilisé pour la dernière fois.

Suppression et recréation de comptes de service

Il est possible de supprimer un compte de service puis de créer un nouveau compte de service avec le même nom.

Lorsque vous supprimez un compte de service, ses liaisons de rôles ne sont pas immédiatement supprimées. Au lieu de cela, les liaisons de rôles répertorient le compte de service avec le préfixedeleted:. Pour un exemple, voir Politiques avec des membres supprimés.

Si vous créez un nouveau compte de service avec le même nom qu’un compte de service récemment supprimé, les anciennes liaisons peuvent encore exister ; cependant, elles ne s’appliqueront pas au nouveau compte de service, même si les deux comptes ont la même adresse électronique. Ce comportement se produit parce que les comptes de service reçoivent un ID unique dans la gestion des identités et des accès (IAM) lors de leur création. En interne, toutes les liaisons de rôles sont accordées en utilisant ces ID, et non l’adresse électronique du compte de service. Par conséquent, toute liaison de rôle qui existait pour un compte de service supprimé ne s’applique pas à un compte de service de nouvelles qui utilise la même adresse électronique.

De même, si vous attachez un compte de service à une ressource, puis supprimez le compte de service et créez un nouveau compte de service avec le même nom,le nouveau compte de service ne sera pas attaché à la ressource.

Pour éviter ce comportement inattendu, envisagez d’utiliser un nouveau nom unique pour chaque compte de service. De plus, si vous supprimez accidentellement un compte de service, vous pouvez essayer d’annuler la suppression du compte de service au lieu de créer un nouveau compte de service.

Si vous ne pouvez pas annuler la suppression du compte de service d’origine et que vous devez créer un nouveau compte de service avec le même nom et les mêmes rôles, vous devez accorder ces rôles au nouveau compte de service. Pour plus de détails, voirPolitiques avec des membres supprimés.

Si vous avez également besoin que le nouveau compte de service soit attaché aux mêmes ressources que le compte de service d’origine, effectuez l’une des opérations suivantes :

• Pour les instances de Compute Engine, vous pouvez modifier le compte de service qui est attaché à l’instance pour remplacer le compte de service d’origine par le nouveau compte de service.
• Pour toutes les autres ressources, vous devez supprimer la ressource existante, puis créer une nouvelle ressource du même type et attacher le nouveau compte de service.

Permissions pour les comptes de service

Cette section décrit les scénarios courants pour les permissions accordées aux comptes de service, ou aux comptes d’utilisateur qui ont les permissions d’usurper l’identité des comptes de service :

• Attribution d’autorisations minimales aux comptes de service
• Attribution d’autorisations aux comptes de service pour les scénarios courants

Attribution d’autorisations minimales aux comptes de service

Comme pour tous les types de membres, vous ne devez accorder au compte de service que l’ensemble minimal d’autorisations nécessaires pour atteindre son objectif. Découvrez comment accorder des rôles à tous les types de membres,y compris les 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 a despermissions. Il est donc important de configurer les autorisations de vos comptes de service avec soin, c’est-à-dire d’être strict sur les personnes de votre équipe qui peuvent agir en tant que (ou usurper l’identité) d’un compte de service. Soyez particulièrement prudent lorsque vous autorisez des utilisateurs à usurper l’identité de comptes de service hautement privilégiés, tels que les comptes de service par défaut du moteur de calcul et du moteur d’application.

Les utilisateurs ayant des rôles IAM pour mettre à jour les instances du moteur d’application et du moteur de calcul (tels que le Deployer du moteur d’application ou l’Admin de l’instance de calcul) peuvent effectivement exécuter du code en tant que comptes de service utilisés pour exécuter ces instances, et obtenir indirectement l’accès à toutes les ressources auxquelles les comptes de service ont accès. De même,l’accès SSH à une instance de Compute Engine peut également fournir la possibilité d’exécuter du code en tant que cette instance.

Les 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, et chacun d’entre eux nécessite certaines autorisations. Cette section décrit les scénarios courants et les autorisations requises.

Attachement des comptes de service aux ressources

Si vous voulez démarrer un travail de longue durée qui s’authentifie en tant que compte de service,vous devez attacher un compte de service à la ressource qui exécutera le travail.

Permissions:

• Permissions de créer la ressource
• iam.serviceAccounts.actAs

Pour trouver les rôles qui incluent ces permissions, recherchez les permissions dans la liste des rôles.

Il existe plusieurs ressources Google Cloud différentes qui peuvent exécuter des travaux à exécution prolongée en tant que comptes de service. Voici quelques exemples de ces ressources :

• Compute Engine VMs
• App Engine apps
• Cloud Functions

Lorsque vous créez ces ressources, vous avez la possibilité de joindre un compte de service. Ce compte de service agit comme l’identité de la ressource.

Pour créer une ressource et joindre un compte de service, vous devez avoir les autorisations pour créer cette ressource et l’autorisation d’usurper l’identité du compte de service que vous allez joindre à la ressource. L’autorisation d’usurper l’identité du compte de service est fournie par tout rôle qui inclut l’autorisation iam.serviceAccounts.actAs.

Après avoir créé la ressource et y avoir attaché un compte de service, vous pouvez démarrer un travail de longue durée sur la ressource. Le travail s’exécute en tant que compte de service qui est attaché à la ressource, et utilise ce compte de service pour autoriser les demandes aux API de Google Cloud.

Pour en savoir plus sur l’attachement des comptes de service aux ressources, voirAttacher un compte de service à une ressource.

Imprimer directement un compte de service

Permissions:

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

Rôles :

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

Une fois les autorisations requises accordées, un utilisateur (ou un service) peut directement impersonnaliser (ou affirmer) l’identité d’un compte de service dans quelques scénarios courants.

Premièrement, l’utilisateur peut obtenir des informations d’identification à court terme pour le compte de service en utilisant la permissioniam.serviceAccounts.getAccessToken et en appelant la méthodegenerateAccessToken(). En utilisant des informations d’identification à court terme, un utilisateur peut émettre des commandes àGoogle Cloud et peut accéder à toutes les ressources auxquelles le compte de service a accès. Par exemple, ce flux permet à un utilisateur d’utiliser le drapeaugcloud --impersonate-service-account pour se faire passer pour le compte de service sans nécessiter l’utilisation d’une clé de compte de service externe téléchargée.

Deuxièmement, l’utilisateur peut obtenir des artefacts signés par la clé privée gérée par Google du compte de service en utilisant la permission iam.serviceAccounts.signBlob et en appelant la méthodesignBlob()ousignJwt(). La clé privée gérée par Google est toujours conservée sous séquestre et n’est jamais exposée directement. signBlob() permet de signer des charges utiles arbitraires (telles que des URL signées parCloud Storage), tandis que signJwt() permet uniquement de signer des JWT bien formés.

Enfin, l’utilisateur peut usurper l’identité (ou affirmer) du compte de service sans jamais récupérer une créance pour le compte de service. Il s’agit d’un cas d’utilisation avancé,et il n’est pris en charge que pour l’accès programmatique utilisant la méthodegenerateAccessToken(). Dans les scénarios avec au moins 3 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 se voit accorder la permissioniam.serviceAccounts.implicitDelegation sur B, et si B se voit accorder la permission iam.serviceAccounts.getAccessToken sur C.

Génération de jetons d’identification OpenID Connect (OIDC)

Permissions:

• iam.serviceAccounts.getOpenIdToken

Rôles :

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

Un utilisateur (ou un service) peut générer un jeton JWT compatible OpenID Connect (OIDC) signé par le fournisseur OIDC de Google (accounts.google.com) qui représente l’identité du compte du service utilisant l’autorisation iam.serviceAccounts.getOpenIdToken.

Ces jetons ne sont pas directement acceptés par la plupart des API de Google sans que votre organisation déploie une fédération d’identité supplémentaire pour accorder l’accès àGoogle. Il existe quelques exceptions – par exemple, Identity-Aware Proxy, qui permet un accès basé sur les OIDC aux applications gérées par les utilisateurs.

Génération de clés privées externes

Permissions:

• 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 être utilisé pour 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 Application Default Credentials (ADC),ou avec la commandegcloud auth activate-service-account. Toute personne qui obtient l’accès à la clé aura alors un accès complet à toutes les ressources auxquelles le compte de service a accès. Ce type de clé privée doit être traité avec la plus grande attention, et doit être considéré comme moins sûr au fur et à mesure de son existence. Par conséquent, la rotation du matériel de clé privée est essentielle pour maintenir une sécurité forte.

Gestion des clés de compte de service

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

• Les clés gérées par Google Cloud. Ces clés sont utilisées par les services Google Clouds tels que App Engine et Compute Engine. Elles ne peuvent pas être téléchargées, et sont automatiquement tournées et utilisées pour la signature pendant un maximum de deux semaines. 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 recommandons de mettre en cache le jeu de clés publiques pour un compte de service pendant au plus 24 heures afin de vous assurer que vous avez toujours accès au jeu de clés actuel.

• Clés gérées par l’utilisateur. Ces clés sont créées, téléchargeables et gérées par les utilisateurs. Après les avoir supprimées du compte de service, vous ne pouvez plus les utiliser pour vous authentifier.

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

• Stockage des clés
• Distribution des clés
• Révocation des clés
• Rotation des clés
• Protection des clés contre les utilisateurs non autorisés
• Récupération des clés

Toute personne ayant accès à une clé privée valide pour un compte de service sera en mesure d’accéder aux ressources par le biais du compte de service. Notez que le cycle de vie de l’accès de la clé au compte de service (et donc, les données auxquelles le compte de service a accès) est indépendant du cycle de vie de l’utilisateur qui a téléchargé la clé.

Découragez toujours les développeurs de vérifier les clés dans le code source ou de les laisser dans le répertoire Downloads de leur poste de travail.

Pour renforcer la sécurité des clés, suivez les conseils ci-dessous :

• Utilisez l’API de compte de service IAM pour faire tourner automatiquement vos clés de compte de service. Vous pouvez faire tourner une clé en créant une nouvelle clé, en changeant d’application pour utiliser la nouvelle clé, puis en supprimant l’ancienne clé. Utilisez les méthodes serviceAccount.keys.create()et serviceAccount.keys.delete() ensemble pour automatiser la rotation. Les clés gérées par Google Cloud font l’objet d’une rotation environ une fois par semaine.

  • Utilisez la méthode serviceAccount.keys.list() pour auditer les comptes de service et les clés.

Utilisation des comptes de service avec Compute Engine

Les instances de Compute Engine doivent être exécutées en tant que comptes de service pour avoir accès aux autres ressources Google Cloud. Pour vous assurer que vos instancesCompute Engine sont plus sécurisées, considérez les 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éthodeinstances.setServiceAccount.

• Vous pouvez attribuer des rôles IAM aux comptes de servicepour définir ce à quoi ils peuvent accéder. Dans de nombreux cas, vous n’aurez plus besoin de vous appuyer sur les scopes. Cela vous donne l’avantage de pouvoir modifier les permissions du compte de service d’uneVM sans recréer l’instance.

• Puisque les instances dépendent de leurs comptes de service pour avoir accès aux ressources de Google Cloud, évitez de supprimer les comptes de service lorsqu’ils sont encore utilisés par des instances en cours d’exécution. Si vous supprimez les comptes de service, lesinstances peuvent commencer à échouer leurs opérations.

Bonnes pratiques

• Spécifiez qui peut agir en tant que comptes de service. Les utilisateurs qui sont des utilisateurs de compte de service pour un compte de service peuvent accéder indirectement à toutes les ressources auxquelles le compte de service a accès. Par conséquent, soyez prudent lorsque vous accordez le rôle d’utilisateur de compte de service à un utilisateur.

• Attribuez au compte de service uniquement l’ensemble minimal de permissions nécessaires pour atteindre son objectif. Apprenez à attribuer des rôles à tous les types de membres, y compris les comptes de service.

• Créer des comptes de service pour chaque service avec seulement les autorisations requises pour ce service.

• Utiliser le nom d’affichage d’un compte de service pour garder la trace des comptes de service. Lorsque vous créez un compte de service, renseignez son nom d’affichage avec l’objectif du compte de service.

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

• Mettez en place des processus pour automatiser la rotation des clés de compte de service gérées par l’utilisateur.

• Profitez de l’API de compte de service IAM pour mettre en œuvre la rotation des clés.

• Auditez les comptes de service et les clés à l’aide de la méthodeserviceAccount.keys.list() ou de la pageLogs Viewer de la console.

• Ne supprimez pas les comptes de service qui sont utilisés par des instances en cours d’exécution surApp Engine ou Compute Engine, sauf si vous souhaitez que ces applications tolèrent l’accès au compte de service.