Bonnes pratiques pour utiliser la fédération d'identité de charge de travail

La fédération d'identité de charge de travail permet aux applications exécutées en dehors de Google Cloud d'emprunter l'identité d'un compte de service en utilisant les identifiants d'un fournisseur d'identité externe.

La fédération d'identité de charge de travail peut vous aider à améliorer la sécurité en permettant aux applications d'utiliser les mécanismes d'authentification fournis par l'environnement externe et à remplacer les clés de compte de service.

Pour utiliser la fédération d'identité de charge de travail, vous devez la configurer de manière à vous protéger des menaces suivantes :

• Spoofing : un acteur malintentionné peut tenter de falsifier l'identité d'un autre utilisateur pour obtenir un accès non autorisé aux ressources Google Cloud.
• Élévation des privilèges : un acteur malintentionné peut tirer parti de la fédération d'identité de charge de travail pour accéder à des ressources auxquelles il n'aurait pas accès autrement.
• Non-répudiation : un acteur malintentionné peut dissimuler son identité et ses actions en utilisant des identifiants externes qui compliqueraient de remonter à lui.

Ce guide présente les bonnes pratiques pour choisir quand utiliser la fédération d'identité de charge de travail et comment la configurer de manière à réduire les risques au maximum.

Quand utiliser la fédération d'identité de charge de travail

Bonnes pratiques

Utilisez la fédération d'identité de charge de travail pour les applications ayant accès aux identifiants ambiants.
Utilisez un échange de jetons supplémentaire pour utiliser des identifiants ambiants non compatibles avec la fédération d'identité de charge de travail.
Utilisez la fédération d'identité de charge de travail pour réduire le nombre d'identifiants nécessitant une rotation.

Utiliser la fédération d'identité de charge de travail pour les applications ayant accès aux identifiants ambiants

Les applications exécutées sur des fournisseurs cloud autres que Google Cloud ont souvent accès aux identifiants ambiants. Il s'agit d'identifiants que l'application peut obtenir sans avoir à effectuer d'authentification supplémentaire. Voici quelques exemples :

• Sur AWS, les applications déployées sur EC2 peuvent utiliser des profils d'instance pour assumer un rôle et obtenir des identifiants temporaires.
• Sur Azure, les applications peuvent utiliser des identités gérées pour obtenir des jetons d'accès.
• Dans GitHub Actions, les workflows peuvent obtenir des jetons d'ID qui reflètent l'identité de la tâche de déploiement.

Si les identifiants ambiants sont des jetons OpenID Connect (OIDC), des assertions SAML ou des identifiants AWS, vous pouvez configurer la fédération d'identité de charge de travail pour permettre aux applications d'échanger ces identifiants contre des jetons d'accès Google éphémères. Si les identifiants ambiants utilisent un format différent, vous pouvez d'abord les échanger contre un jeton OIDC ou une assertion SAML, puis les utiliser pour la fédération d'identité de charge de travail.

Utilisez la fédération d'identité de charge de travail chaque fois qu'une application doit accéder à Google Cloud et qu'elle a accès aux identifiants ambiants.

Utiliser un échange de jetons supplémentaire pour utiliser des identifiants ambiants non compatibles avec la fédération d'identité de charge de travail

Dans certains cas, une application peut avoir accès aux identifiants ambiants, mais les types d'identifiants ne sont pas compatibles avec la fédération d'identité de charge de travail. Dans ces cas, vérifiez si un échange de jetons supplémentaire vous permet de convertir les identifiants ambiants en un type d'identifiant que vous pouvez utiliser pour la fédération d'identité de charge de travail.

Par exemple, si votre application s'exécute dans un environnement Active Directory, elle peut avoir accès aux identifiants Kerberos. Si vous disposez dans votre environnement d'un fournisseur d'identité tel qu'ADFS (Active Directory Federation Services) qui est compatible avec l'authentification Windows intégrée, vous pouvez vous authentifier à l'aide de ces identifiants Kerberos auprès du fournisseur d'identité et obtenir un jeton d'accès OAuth qui utilise le format JWT. Grâce à ce jeton d'accès et à la fédération d'identité de charge de travail, vous pouvez ensuite laisser l'application effectuer un deuxième échange de jetons afin d'obtenir des identifiants Google éphémères.

Le chaînage d'échange de jetons augmente la complexité et peut entraîner des dépendances supplémentaires. En revanche, il vous évite d'avoir à gérer et à sécuriser des clés de compte de service.

Utiliser la fédération d'identité de charge de travail pour réduire le nombre d'identifiants nécessitant une rotation

Les applications qui s'intègrent à un fournisseur d'identité OpenID ou SAML utilisent souvent un code secret du client (ou un autre type de secret) pour s'authentifier auprès du fournisseur d'identité. En règle générale, ce secret est stocké dans la configuration de l'application. Pour permettre à une telle application d'accéder à Google Cloud, vous devez choisir entre les options suivantes :

1. Créer une clé de compte de service et la stocker avec l'autre secret
2. Utiliser des jetons émis par le fournisseur d'identité existant et les échanger contre des identifiants Google via la fédération d'identité de charge de travail

La première option nécessite deux secrets, mais la seconde n'en nécessite qu'un. Réduire le nombre de secrets peut vous aider à simplifier la rotation des secrets, ce qui contribue à améliorer la sécurité.

Se protéger contre les menaces de spoofing

Un pool d'identités de charge de travail ne contient pas d'identités ou de comptes utilisateur, ce qui le différencie d'un annuaire d'utilisateurs tel que Cloud Identity. À la place, un pool d'identités de charge de travail représente une vue qui affiche les identités des fournisseurs d'identité externes afin de pouvoir les utiliser comme comptes principaux IAM.

Selon la configuration du pool d'identités de charge de travail et de ses fournisseurs, la même identité externe peut être représentée sous la forme de plusieurs comptes principaux IAM différents, ou plusieurs identités externes peuvent être mappées sur le même compte principal IAM. De telles ambiguités peuvent permettre à des acteurs malintentionnés de lancer des attaques de spoofing.

La section suivante décrit les bonnes pratiques qui vous aident à éviter les mappages ambigus et à réduire le risque de menaces de spoofing.

Bonnes pratiques :

Utilisez des conditions d'attribut lors de la fédération avec GitHub ou d'autres fournisseurs d'identité mutualisés.
Utilisez un projet dédié pour gérer les pools et les fournisseurs d'identités de charge de travail.
Utilisez des contraintes de règles d'administration pour désactiver la création de fournisseurs de pools d'identités de charge de travail dans d'autres projets.
Utilisez un seul fournisseur par pool d'identités de charge de travail pour éviter les conflits de sujet.
Évitez la fédération avec le même fournisseur d'identité deux fois.
Protégez le point de terminaison des métadonnées OIDC du fournisseur d'identité.
Utilisez l'URL du fournisseur du pool d'identités de charge de travail comme audience.
Utilisez des attributs immuables dans les mappages d'attributs.
Utilisez des attributs réutilisables dans les mappages d'attributs.
N'autorisez pas la modification des mappages d'attributs.
Ne vous fiez pas aux attributs non stables ou fiables.

Utilisez des conditions d'attribut lors de la fédération avec GitHub ou d'autres fournisseurs d'identité mutualisés

La fédération d'identité de charge de travail ne gère pas un annuaire de comptes utilisateur, mais met en œuvre des identités basées sur des revendications. Par conséquent, lorsque deux jetons sont émis par le même fournisseur d'identité (IdP) et que leurs revendications correspondent à la même valeur google.subject, les deux jetons sont supposés identifier le même utilisateur. Pour savoir quel fournisseur d'identité a émis un jeton, la fédération d'identité de charge de travail inspecte et valide l'URL de l'émetteur du jeton.

Certains fournisseurs, tels que GitHub et Terraform Cloud, utilisent une seule URL d'émetteur pour tous leurs locataires. Pour ces fournisseurs, l'URL de l'émetteur identifie l'ensemble de GitHub ou Terraform Cloud, et non une organisation GitHub ou Terraform Cloud spécifique.

Lorsque vous faites appel à ces fournisseurs d'identité, il ne suffit pas de laisser la fédération d'identité de charge de travail vérifier l'URL d'émetteur d'un jeton pour s'assurer qu'elle provient d'une source fiable et que ses revendications peuvent être approuvées. Nous vous recommandons de configurer une condition d'attribut de fédération d'identité de charge de travail pour vérifier que le jeton provient d'un locataire de confiance ou, dans le cas de GitHub ou de Terraform Cloud, d'une organisation de confiance.

Pour en savoir plus, consultez la section Configurer une condition d'attribut.

Utiliser un projet dédié pour gérer les pools et les fournisseurs d'identités de charge de travail

Au lieu de gérer des pools d'identités de charges de travail et des fournisseurs sur plusieurs projets, utilisez un seul projet dédié pour gérer les pools d'identités de charges de travail et les fournisseurs. L'utilisation d'un projet dédié vous permet d'effectuer les opérations suivantes :

• Vous assurer que seuls des fournisseurs d'identité de confiance sont utilisés pour la fédération d'identité de charge de travail
• Contrôler de manière centralisée l'accès à la configuration des pools d'identités de charge de travail et des fournisseurs
• Appliquer des mappages d'attributs et des conditions cohérents pour tous les projets et applications

Vous pouvez utiliser des contraintes de règles d'administration pour appliquer la discipline consistant à utiliser un projet dédié pour gérer les pools de charges de travail et les fournisseurs.

Utiliser des contraintes de règles d'administration pour désactiver la création de fournisseurs de pools d'identités de charge de travail dans d'autres projets

Les utilisateurs autorisés à créer des fournisseurs de pools d'identités de charge de travail peuvent créer des pools et des fournisseurs d'identités de charge de travail qui peuvent être redondants avec ceux que vous gérez dans un projet dédié.

Vous pouvez empêcher la création de nouveaux fournisseurs de pools d'identités de charge de travail en utilisant la contrainte de règle d'administration constraints/iam.workloadIdentityPoolProviders avec une règle définie sur Tout refuser.

Appliquez ces contraintes à la racine de votre hiérarchie organisationnelle pour refuser la création par défaut de nouveaux fournisseurs de pools d'identités de charge de travail. Créez des exceptions pour les projets dans lesquels vous souhaitez autoriser la gestion des pools d'identités de charge de travail et des fournisseurs en appliquant une contrainte de stratégie qui autorise certains comptes AWS ou fournisseurs OIDC fiables.

Utiliser un seul fournisseur par pool d'identités de charge de travail pour éviter les conflits de sujet

La fédération d'identité de charge de travail vous permet de créer plusieurs fournisseurs par pool d'identités de charge de travail. L'utilisation de plusieurs fournisseurs peut être utile si les identités sont gérées par plusieurs fournisseurs, mais que vous souhaitez masquer cette complexité pour les charges de travail exécutées sur Google Cloud.

L'utilisation de plusieurs fournisseurs présente un risque de conflits de sujets, où le mappage d'attributs pour google.subject d'un fournisseur renvoie la même valeur que le mappage d'attributs pour un autre fournisseur. Le résultat d'une telle collision est que plusieurs identités externes sont mappées sur le même compte principal IAM, rendant les identités externes impossibles à distinguer dans Cloud Audit Logs.

Pour éviter les conflits de sujet, utilisez un seul fournisseur par pool d'identités de charge de travail. Si vous devez fédérer avec plusieurs fournisseurs, créez plusieurs pools d'identités de charge de travail, chacun utilisant un seul fournisseur d'identité de charge de travail.

Éviter la fédération avec le même fournisseur d'identité deux fois

Vous pouvez fédérer avec le même fournisseur d'identité plusieurs fois en créant plusieurs fournisseurs d'identité de pool de charge de travail qui utilisent la même configuration ou une configuration similaire. Si ces fournisseurs appartiennent au même pool d'identités de charge de travail, cette configuration peut entraîner des collisions de sujets. Si les fournisseurs appartiennent à différents pools d'identités de charge de travail, il ne peut pas y avoir de conflits de sujets et la même identité externe est représentée à la place de comptes principaux IAM différents.

Le mappage d'une identité externe unique sur plusieurs comptes principaux IAM rend plus difficile l'analyse des ressources auxquelles une identité externe donnée a accès. Une telle ambiguïté peut également augmenter le risque lorsque vous essayez de révoquer l'accès : un administrateur pourrait révoquer l'accès à un compte principal, mais ignorer l'existence d'un autre compte principal. Par conséquence, l'identité externe conserverait donc l'accès.

Pour réduire le risque d'ambiguïté, évitez de fédérer le même fournisseur d'identité plusieurs fois. À la place, créez un pool d'identités de charge de travail et un fournisseur uniques, et utilisez un mappage et une condition d'attribut garantissant qu'ils peuvent être utilisés pour toutes les identités externes nécessitant un accès aux ressources Google Cloud.

Protéger le point de terminaison des métadonnées OIDC du fournisseur d'identité

Lorsque vous fédérez avec un fournisseur OpenID Connect, la fédération d'identité de charge de travail télécharge régulièrement les métadonnées OIDC de votre fournisseur d'identité. La fédération d'identité de charge de travail utilise les métadonnées du fournisseur d'identité et le jeu de clés Web JSON (JWKS) pour valider les jetons.

Pour assurer l'authenticité, la communication avec votre fournisseur d'identité est sécurisée à l'aide de TLS. Si votre fournisseur est déployé derrière un équilibreur de charge ou un proxy inverse qui met fin au protocole TLS, la connexion TLS garantit l'authenticité de l'équilibreur de charge ou du proxy inverse, mais pas du fournisseur d'identité réel.

Un acteur malintentionné pourrait tirer parti de cette configuration en lançant une attaque MITM ("man in the middle") dans laquelle il reconfigure l'équilibreur de charge pour lui permettre de transmettre des requêtes JWKS à un point de terminaison malveillant livrant un ensemble de clés différent. Échanger les JWKS permet à un acteur malintentionné de signer des jetons considérés comme valides par la fédération d'identité de charge de travail et peut leur permettre de simuler les identités d'autres utilisateurs.

Pour vous protéger contre l'échange de JWKS, assurez-vous que votre fournisseur d'identité est déployé de manière à le protéger contre les attaques MITM.

Utiliser l'URL du fournisseur du pool d'identités de charge de travail comme audience

Lorsque vous fédérez avec un fournisseur OpenID Connect, la fédération d'identité de charge de travail vérifie que l'audience des jetons (encodés dans la revendication aud) correspond au paramètre d'audience autorisé du fournisseur. De même, lorsque vous fédérez avec un fournisseur SAML, la fédération d'identité de charge de travail vérifie que l'assertion SAML spécifie une restriction d'audience correspondant à l'audience attendue.

Par défaut, la fédération d'identité de charge de travail s'attend à ce que l'audience corresponde à l'URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID qui identifie de manière unique le fournisseur de pools d'identités de charge de travail. Exiger des jetons et des assertions pour utiliser cette URL en tant qu'audience permet de réduire le risque d'attaque de type "confused deputy". Dans ce type d'attaque, un acteur malintentionné présente un jeton ou une assertion SAML auprès de la fédération d'identité de charge de travail, qui n'est pas destiné à être utilisé pour la fédération d'identité de charge de travail, mais pour une autre API.

Exiger le jeton ou l'assertion pour contenir l'URL du fournisseur de pool d'identités de charge de travail cible vous permet de vous assurer que les clients ne peuvent utiliser que les jetons et les assertions émis spécifiquement pour la fédération d'identité de charge de travail.

Utiliser des attributs immuables dans les mappages d'attributs

Pour accorder une autorisation d'identité externe afin d'emprunter l'identité d'un compte de service, vous créez une liaison IAM qui référence l'identité externe par sujet, groupe ou attribut personnalisé. Le sujet, le groupe et les attributs personnalisés de l'identité externe sont dérivés des attributs que le fournisseur d'identité externe transmet à la fédération d'identité de charge de travail lors de l'échange de jetons.

Certains fournisseurs d'identité permettent aux utilisateurs de modifier certains de leurs attributs. Par exemple, un utilisateur peut être autorisé à modifier son adresse e-mail ou ses alias. Si vos liaisons IAM font référence à des attributs modifiables, les utilisateurs peuvent perdre accidentellement l'accès à certaines ressources en modifiant leur profil utilisateur. Pire encore, les acteurs malintentionnés peuvent être en mesure d'obtenir un accès non autorisé à d'autres ressources en modifiant délibérément leurs attributs utilisateur afin de les faire correspondre à des liaisons IAM existantes.

Pour se protéger contre cette menace de spoofing, limitez les mappages d'attributs aux attributs qui ne peuvent pas être modifiés par l'utilisateur, ou qui ne peuvent pas être modifiés du tout.

Utiliser des attributs réutilisables dans les mappages d'attributs

Lorsque vous autorisez une identité externe à emprunter l'identité d'un compte de service, puis vous supprimez l'utilisateur du fournisseur d'identité externe, la liaison IAM de ce compte reste en place.

Si, par la suite, vous ajoutez un nouvel utilisateur à votre fournisseur d'identité externe et que celui-ci partage certains attributs avec l'utilisateur précédemment supprimé (par exemple, la même adresse e-mail), les anciens et les nouveaux utilisateurs ne seront pas identifiables pour la fédération d'identité de charge de travail. Par conséquent, une liaison IAM destinée à ne faire référence qu'à l'ancien utilisateur peut également s'appliquer au nouvel utilisateur.

Pour éviter ces ambiguïtés, utilisez des mappages d'attributs qui s'appuient exclusivement sur des attributs qui ne peuvent pas être réutilisés avec le temps, comme un ID utilisateur unique.

Si le règlement de votre entreprise autorise la réutilisation d'attributs tels que les adresses e-mail, évitez d'utiliser ces attributs dans les mappages d'attributs et privilégiez un attribut différent qui restera unique au fil du temps.

Ne pas autoriser la modification des mappages d'attributs

La fédération Workload Identity utilise des mappages d'attributs pour sélectionner les attributs fournis par le fournisseur d'identité externe qui doivent être intégrés à un jeton STS et leur traduction. La configuration des mappages d'attributs est une étape clé pour configurer la relation d'approbation entre le fournisseur d'identité externe et Google Cloud.

Les mappages d'attributs sont également essentiels à la sécurité avec l'utilisation de la fédération Workload Identity : si vous avez autorisé un compte principal fédéré ou un ensemble de comptes principaux à usurper l'identité d'un compte de service, puis modifier le mappage d'attributs, vous pouvez modifier quels utilisateurs ont accès au compte de service.

Pour modifier les mappages d'attributs, vous devez disposer de l'autorisation iam.googleapis.com/workloadIdentityPoolProviders.update. Les rôles contenant cette autorisation sont les suivants :

• Propriétaire (roles/owner)
• Rôle IAM d'administrateur de pools Workload Identity (roles/iam.workloadIdentityPoolAdmin)

Si un utilisateur malveillant est autorisé à modifier les mappages d'attributs, il peut éventuellement modifier les règles de mappage de manière à usurper son identité et à accéder à un compte de service. Pour éviter ces modifications malveillantes, assurez-vous que seuls quelques utilisateurs administratifs sont autorisés à modifier les mappages d'attributs.

Envisagez de créer un projet Cloud dédié pour gérer les pools Workload Identity afin de limiter le risque que des utilisateurs se voient attribuer accidentellement l'un de ces rôles à un niveau supérieur de la hiérarchie des ressources.

Ne pas se fier aux attributs non stables ou fiables

Un fournisseur d'identité utilise des attributs pour communiquer des informations sur les utilisateurs authentifiés. Les fournisseurs d'identité garantissent généralement que certains attributs font autorité, mais pas d'autres. Par exemple, un fournisseur d'identité externe peut intégrer à la fois un nom d'utilisateur et un ID utilisateur dans un jeton OIDC. Ces deux attributs identifient un utilisateur de manière unique et peuvent sembler interchangeables. Toutefois, le fournisseur d'identité externe peut garantir que l'ID utilisateur est stable et faire autorité, mais autoriser la modification des noms d'utilisateur.

Si vos mappages d'attributs reposent sur des attributs qui ne sont pas stables ou fiables, alors un utilisateur malveillant pourrait alors usurper l'identité de l'utilisateur en modifiant son profil utilisateur dans le fournisseur d'identité externe. Par exemple, il peut remplacer son nom d'utilisateur par celui d'un utilisateur récemment supprimé du fournisseur d'identité externe, mais ayant encore accès à un compte de service sur Google Cloud.

Pour éviter de telles attaques, assurez-vous que vos mappages d'attributs ne se basent que sur des attributs garantis comme stables et autorisés par le fournisseur d'identité externe.

Se protéger contre les menaces de non-répudiation

Chaque fois que vous remarquez une activité suspecte affectant l'une de vos ressources sur Google Cloud, Cloud Audit Logs est une source importante d'informations permettant de savoir quand l'activité a eu lieu et quels utilisateurs ont été impliqués.

Lorsqu'une application utilise la fédération d'identité de charge de travail, elle emprunte l'identité d'un compte de service. Dans Cloud Audit Logs, toute activité effectuée par l'application est attribuée au compte de service dont l'identité a été empruntée. Pour reconstruire la chaîne complète d'événements ayant entraîné l'activité, vous devez être en mesure de mettre en corrélation les journaux d'audit Cloud avec les journaux de votre fournisseur d'identité afin de savoir quelle identité externe a été impliquée et pourquoi l'activité a été effectuée.

Cette section présente les bonnes pratiques à suivre pour conserver un outil d'audit non-répudiable.

Bonnes pratiques

Activer les journaux d'accès aux données pour les API IAM.
Utilisez un mappage de sujet unique.

Activer les journaux d'accès aux données pour les API IAM

Pour vous aider à identifier et à comprendre les scénarios d'emprunt d'identité du compte de service, des services tels que Compute Engine incluent une section serviceAccountDelegationInfo dans les journaux Cloud Audit. Lorsqu'une application utilise la fédération d'identité de charge de travail, cette section inclut le sujet du compte principal qui a été utilisé pour emprunter l'identité du compte de service.

Tous les services n'incluent pas les détails d'emprunt d'identité dans Cloud Audit Logs. Afin de maintenir une piste d'audit non répétitive, vous devez également enregistrer tous les événements d'usurpation d'identité en activant les journaux d'accès aux données pour l'API Security Token Service et l'API Identity and Access Management. Activez ces journaux pour tous les projets Cloud contenant des pools d'identités de charge de travail ou des comptes de service utilisés pour la fédération d'identité de charge de travail.

En activant ces journaux, vous vous assurez qu'une entrée est ajoutée dans Cloud Audit Logs chaque fois qu'une application utilise la fédération d'identité de charge de travail pour échanger un identifiant externe et emprunte l'identité d'un compte de service.

Utiliser un mappage de sujet unique

Le sujet principal utilisé dans la section serviceAccountDelegationInfo des entrées Cloud Audit Logs est déterminé par le mappage des attributs de votre fournisseur de pools d'identités de charge de travail pour google.subject.

Lorsque vous repérez une activité suspecte et que vous devez savoir quelle identité externe a été impliquée, vous devez pouvoir rechercher une identité externe à l'aide de la valeur google.subject correspondante.

De même, lorsqu'une identité externe est compromise et que vous devez savoir si l'identité a été utilisée pour accéder aux ressources Google Cloud, vous devez pouvoir rechercher les entrées Cloud Audit Logs correspondant à l'identité externe.

Lorsque vous définissez le mappage d'attributs pour un fournisseur de pool d'identités de charge de travail, choisissez un mappage unique pour google.subject afin que :

• une identité externe correspond à une seule valeur google.subject ;
• une valeur google.subject correspond à une seule identité externe.
• Vous pouvez rechercher une identité externe à l'aide de sa valeur google.subject.

L'utilisation d'un mappage d'attributs répondant à ces critères d'unicité vous permet de rechercher des identités externes en fonction de leur valeur google.subject, et inversement.

Se protéger contre les menaces d'élévation des privilèges

Pour appliquer le principe du moindre privilège lorsque vous utilisez la fédération d'identité de charge de travail, vous devez :

• limiter le nombre d'identités externes pouvant emprunter l'identité d'un compte de service ;
• limiter les ressources auxquelles un compte de service peut accéder.

Une configuration trop permissive peut entraîner une situation dans laquelle un acteur malintentionné peut utiliser une identité externe pour élever ses privilèges et accéder à des ressources auxquelles il ne devrait pas avoir accès.

Les sections suivantes décrivent les bonnes pratiques à suivre pour vous protéger contre les menaces d'élévation des privilèges.

Bonnes pratiques

Utilisez des comptes de service résidant dans le même projet que les ressources auxquelles vous devez accéder.
Utilisez un compte de service dédié pour chaque application.
Évitez d'accorder l'accès à tous les membres d'un pool.

Utiliser des comptes de service résidant dans le même projet que les ressources auxquelles vous devez accéder

Lorsqu'un client utilise la fédération d'identité de charge de travail à l'aide de bibliothèques clientes ou de l'API REST, il suit un processus en trois étapes :

1. Obtenez des identifiants auprès du fournisseur d'identité approuvé.
2. Échangez les identifiants contre un jeton Security Token Service.
3. Utilisez le jeton du service Security Token Service pour emprunter l'identité d'un compte de service et obtenir un jeton d'accès Google éphémères.

Pour la dernière étape, utilisez un compte de service résidant dans le même projet que les ressources auxquelles vous devez accéder. L'utilisation d'un compte de service géré dans le même projet vous aide à appliquer des autorisations d'accès plus restrictives et à déterminer plus facilement quand le compte de service n'est plus nécessaire.

Utiliser un compte de service dédié pour chaque application

Si plusieurs applications utilisent la fédération d'identité de charge de travail pour accéder aux ressources d'un même projet, créez un compte de service dédié pour chaque application. L'utilisation de comptes de service spécifiques aux applications vous permet d'éviter les autorisations excessives en n'accordant l'accès qu'aux ressources requises par chaque application.

Éviter d'accorder l'accès à tous les membres d'un pool

Pour qu'une identité externe puisse emprunter l'identité d'un compte de service, vous devez lui attribuer le rôle roles/iam.workloadIdentityUser sur le compte de service. Lorsque vous attribuez ce rôle, évitez de l'attribuer à tous les membres du pool d'identités de charge de travail. Attribuez-le plutôt à des identités externes spécifiques ou à des identités correspondant à certains critères.

Au départ, le nombre d'utilisateurs externes nécessitant un accès aux ressources Google Cloud peut être réduit. La condition d'attribut de votre pool d'identités de charge de travail et la configuration de votre fournisseur d'identité peuvent donc n'autoriser que quelques identités externes à utiliser la fédération d'identité de charge de travail.

Lorsque vous intégrerez ultérieurement de nouvelles charges de travail à Google Cloud, vous devrez peut-être modifier la configuration de votre fournisseur d'identité ou la condition d'attribut du pool d'identités de charge de travail pour autoriser les identités externes supplémentaires.

En n'accordant le rôle roles/iam.workloadIdentityUser qu'à des identités externes spécifiques, vous pouvez vous assurer que vous pouvez développer en toute sécurité un pool d'identités de charge de travail sans accorder par inadvertance l'accès avec emprunt d'identité à trop d'identités externes.

Étapes suivantes

• Découvrez les bonnes pratiques d'utilisation des comptes de service.
• Découvrez les bonnes pratiques pour gérer les clés de compte de service.