Les comptes principaux peuvent s'authentifier de différentes manières à l'aide de comptes de service. Chaque type d'authentification nécessite que le compte principal dispose d'autorisations IAM (Identity and Access Management) spécifiques sur le compte de service.
Cette page décrit les rôles que vous pouvez attribuer aux comptes principaux pour leur permettre d'emprunter l'identité de comptes de service ou d'associer des comptes de service à des ressources. Elle décrit également les autorisations dont vous avez besoin dans des scénarios courants.
Pour en savoir plus sur les différentes façons de vous authentifier avec un compte de service, consultez les pages Identifiants du compte de service et Emprunter l'identité d'un compte de service.
Rôles de compte de service
Cette section décrit les rôles qui permettent aux comptes principaux de s'authentifier avec des comptes de service. Pour savoir comment attribuer et révoquer ces rôles, consultez Gérer l'accès aux comptes de service.
Rôle Utilisateur du compte de service
Le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) permet à un compte principal d'associer un compte de service à une ressource. Lorsque le code exécuté sur cette ressource doit s'authentifier, il peut obtenir les identifiants du compte de service associé.
Ce rôle ne permet pas aux comptes principaux de créer des identifiants éphémères pour les comptes de service, ni d'utiliser l'option --impersonate-service-account pour Google Cloud CLI. Pour effectuer ces tâches, vous devez disposer du rôle Créateur de jetons du compte de service sur le compte de service.
Rôle Créateur de jetons du compte de service
Le rôle Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator) permet aux comptes principaux de créer des identifiants éphémères pour un compte de service.
Le rôle de créateur de jetons du compte de service vous permet de créer les types d'identifiants éphémères suivants :
- Jetons d'accès OAuth 2.0 que vous pouvez utiliser pour vous authentifier auprès des API Google
- Jetons d'identification OpenID Connect (OIDC)
- Jetons Web JSON (JWT) signés et blobs binaires
Le rôle de créateur de jetons du compte de service permet également aux comptes principaux d'utiliser l'option --impersonate-service-account pour gcloud CLI. Lorsque vous utilisez cette option, gcloud CLI crée automatiquement des identifiants éphémères pour le compte de service.
Les autorisations du rôle incluent les suivantes :
iam.serviceAccounts.getAccessToken: vous permet de créer des jetons d'accès OAuth 2.0.iam.serviceAccounts.getOpenIdToken: vous permet de créer des jetons d'identification OpenID Connect (OIDC).iam.serviceAccounts.implicitDelegation: permet aux comptes de service d'obtenir des jetons dans une chaîne de délégation.iam.serviceAccounts.signBlob: vous permet de signer des blobs binaires.iam.serviceAccounts.signJwt: vous permet de signer des jetons JWT.
Créateur de jetons d'identité OpenID Connect du compte de service
Le rôle Créateur de jetons d'identité OpenID Connect du compte de service (roles/iam.serviceAccountOpenIdTokenCreator) permet aux comptes principaux de créer des jetons d'identification OIDC de courte durée. Si vous ne devez créer que des jetons d'ID OIDC, utilisez ce rôle. Si vous devez créer d'autres types de jetons, utilisez plutôt le rôle Créateur de jetons de compte de service.
Le rôle inclut l'autorisation iam.serviceAccounts.getOpenIdToken, qui vous permet de créer un jeton d'identification OIDC.
Rôle Utilisateur Workload Identity
Le rôle Utilisateur Workload Identity (roles/iam.workloadIdentityUser) permet aux comptes principaux d'emprunter l'identité des comptes de service des charges de travail GKE.
Les autorisations du rôle incluent les suivantes :
iam.serviceAccounts.getAccessToken: vous permet de créer des jetons d'accès OAuth 2.0.iam.serviceAccounts.getOpenIdToken: vous permet de créer des jetons d'identification OpenID Connect (OIDC).
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.
Rattacher des comptes de service à des ressources
Si vous souhaitez démarrer une tâche de longue durée qui s'authentifie en tant que compte de service, vous devez associer un compte de service à la ressource qui exécutera la tâche.
Autorisations :
- Autorisations pour créer la ressource
iam.serviceAccounts.actAs
Pour rechercher les rôles qui incluent ces autorisations, recherchez les autorisations dans la liste des rôles.
Plusieurs ressources Google Cloud peuvent exécuter des tâches de longue durée en tant que comptes de service. Voici quelques exemples de ressources :
- VM Compute Engine
- Applications App Engine
- Cloud Run Functions
Lorsque vous créez ces ressources, vous avez la possibilité d'y rattacher un compte de service. Ce compte de service sert d'identité à la ressource.
Pour créer une ressource et lui rattacher un compte de service, vous devez disposer des autorisations nécessaires pour créer cette ressource et lui associer le compte de service.
Autorisation d'associer des comptes de service aux ressources fournies par n'importe quel rôle incluant l'autorisation iam.serviceAccounts.actAs, par exemple le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser).
Une fois que vous avez créé la ressource et lui avez rattaché un compte de service, vous pouvez démarrer une tâche de longue durée sur la ressource. La tâche s'exécute en tant que compte de service rattaché à la ressource, et elle utilise ce compte de service pour autoriser les requêtes adressées aux API Google Cloud.
Pour en savoir plus sur le rattachement de comptes de service à des ressources, consultez Rattacher un compte de service à une ressource.
Emprunter l'identité d'un compte de service
Autorisations :
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.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 autre compte de service) peut emprunter l'identité du compte de service dans plusieurs scénarios courants.
Tout d'abord, l'utilisateur peut s'authentifier en tant que compte de service. Par exemple, ils peuvent obtenir des identifiants éphémères pour le compte de service en utilisant l'autorisation iam.serviceAccounts.getAccessToken et en appelant la méthodegenerateAccessToken(). Ils peuvent également utiliser l'option --impersonate-service-account pour que gcloud CLI emprunte l'identité du compte de service. Lorsqu'un utilisateur s'authentifie en tant que compte de service, il peut émettre des commandes vers Google Cloud et accéder à toutes les ressources auxquelles le compte de service a accès.
L'utilisateur peut également obtenir des artefacts signés par la clé privée gérée par Google du 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 l'identité du compte de service sans récupérer les identifiants de celui-ci. Il s'agit d'un cas d'utilisation avancée, 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.serviceAccountOpenIdTokenCreator(Créateur de jetons d'identité OpenID Connect 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.serviceAccountKeyAdmin(Administrateur de clés 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.
Autorisations du compte de service permettant d'activer d'autres fonctionnalités
Certaines autorisations pour les identifiants de compte de service permettent plusieurs fonctionnalités.
Par exemple, iam.serviceAccounts.signBlob et iam.serviceAccounts.signJwt permettent également aux comptes principaux de générer des jetons d'accès et des jetons d'identification pour un compte de service. De plus, comme iam.serviceAccounts.signBlob permet aux comptes principaux de signer n'importe quel type de données, il leur permet également de signer des jetons JWT.
Avant d'ajouter l'une de ces autorisations à des rôles personnalisés, assurez-vous de comprendre les actions que chaque autorisation permet.
Le tableau suivant présente les opérations activées par ces autorisations:
| Autorisation | Opérations activées |
|---|---|
iam.serviceAccounts.getAccessToken |
Obtenir un jeton d'accès pour le compte de service |
iam.serviceAccounts.getOpenIdToken |
Obtenir un jeton d'identification pour le compte de service |
iam.serviceAccounts.signJwt |
|
iam.serviceAccounts.signBlob |
|
Bonnes pratiques concernant l'attribution des rôles sur les comptes de service
Si un compte de service dispose d'autorisations lui permettant d'effectuer des opérations à privilèges élevés, attribuez le rôle Utilisateur du compte de service ou ses autorisations incluses à un utilisateur de ce compte de service avec prudence.
Les comptes de service représentent votre sécurité au niveau du service. La sécurité du service est déterminée par les personnes disposant des rôles IAM nécessaires pour gérer et utiliser les comptes de service, ainsi que par les personnes qui détiennent les clés de compte de service associées à ces comptes de service. Voici quelques-unes des pratiques recommandées pour assurer la sécurité :
- Utilisez l'API Cloud IAM pour auditer les comptes de service ainsi que les clés et les stratégies d'autorisation associées à ces comptes.
- Si vos comptes de service n'ont pas besoin de clés de compte de service, désactivez-les ou supprimez-les.
- Si les utilisateurs n'ont pas besoin d'être autorisés à gérer ou utiliser des comptes de service, supprimez-les de la stratégie d'autorisation applicable.
- Découvrez comment accorder certaines autorisations aux comptes de service peut activer efficacement d'autres fonctionnalités.
- Assurez-vous que les comptes de service disposent du nombre minimal d'autorisations nécessaires. Utilisez les comptes de service par défaut avec prudence, car ils se voient attribuer automatiquement le rôle d'éditeur (
roles/editor) sur le projet.
Pour en savoir plus sur les bonnes pratiques, consultez la page 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 nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
Essai gratuit