Fédération d'identité de charge de travail

Ce document offre un aperçu de la fédération d'identité de charge de travail. Grâce à la fédération d'identité de charge de travail, vous pouvez fournir à des charges de travail sur site ou multicloud un accès aux ressources Google Cloud en utilisant des identités fédérées au lieu d'une clé de compte de service.

Vous pouvez utiliser la fédération d'identité de charge de travail avec des charges de travail qui s'exécutent sur Amazon Web Services (AWS) et Azure ; avec Active Directory sur site ; avec des services de déploiement, tels que GitHub et GitLab et avec n'importe quel fournisseur d'identité (IdP) compatible avec OpenID Connect (OIDC) ou le langage SAML (Security Assertion Markup Language) version 2.0.

Pourquoi utiliser la fédération d'identité de charge de travail ?

Traditionnellement, les applications exécutées en dehors de Google Cloud peuvent utiliser des clés de compte de service pour accéder aux ressources Google Cloud. Toutefois, les clés de compte de service sont des identifiants puissants. Si elles ne sont pas gérées correctement, elles peuvent présenter un risque de sécurité. La fédération d'identité de charge de travail élimine les tâches de maintenance et de sécurité associées aux clés de compte de service.

Avec la fédération d'identité de charge de travail, vous pouvez utiliser Identity and Access Management (IAM) pour accorder aux identités externes des rôles IAM et un accès direct aux ressources Google Cloud. Vous pouvez également accorder l'accès en empruntant l'identité du compte de service.

Pools d'identités de charge de travail

Un pool d'identités de charge de travail est une entité qui vous permet de gérer des identités externes.

En général, nous recommandons de créer un pool pour chacun des environnements autres que Google Cloud ayant besoin d'accéder aux ressources Google Cloud, tels que les environnements de développement, de préproduction ou de production.

Fournisseurs de pools d'identités de charge de travail

Un fournisseur de pools d'identités de charge de travail est une entité qui décrit une relation entre Google Cloud et votre IdP, comprenant les éléments suivants :

  • AWS
  • Azure AD
  • GitHub
  • GitLab
  • Clusters Kubernetes
  • Okta
  • Services AD FS (Active Directory Federation Services) sur site
  • Terraform

La fédération d'identité de charge de travail respecte la spécification d'échange de jetons OAuth 2.0. Vous fournissez un identifiant provenant de votre IdP au service de jetons de sécurité, qui vérifie l'identité sur l'identifiant, puis renvoie en échange un jeton fédéré.

Fournisseur OIDC avec JWK locales

Pour fédérer des charges de travail qui ne possèdent pas de point de terminaison OIDC public, vous pouvez importer des ensembles de clés Web JSON OIDC (JWKS) directement dans le pool. Cette situation est fréquente si Terraform ou GitHub Enterprise est hébergé dans votre propre environnement, ou si certaines contraintes réglementaires vous empêchent d'exposer des URL publiques. Pour en savoir plus, consultez la section Gérer les JWK OIDC (facultatif).

Mappages d'attributs

Les jetons émis par votre fournisseur d'identité externe contiennent un ou plusieurs attributs. Certains fournisseurs d'identité font référence à ces attributs en tant que revendications.

Les jetons Google Security Token Service contiennent également un ou plusieurs attributs, comme indiqué dans le tableau suivant :

Attribut Description
google.subject Obligatoire. Un identifiant unique pour l'utilisateur. Cet attribut est utilisé dans les liaisons de rôle IAM principal:// et apparaît dans les journaux Cloud Logging. La valeur doit être unique et ne peut pas dépasser 127 caractères.
google.groups Facultatif. Un ensemble de groupes auxquels l'identité appartient. Cet attribut est utilisé dans les liaisons de rôle principalSet:// IAM pour accorder l'accès à tous les membres d'un groupe.
attribute.NAME Facultatif. Vous pouvez définir jusqu'à 50 attributs personnalisés et les utiliser dans les liaisons de rôles IAM principalSet:// pour accorder l'accès à toutes les identités avec un certain attribut.

Un mappage d'attributs définit comment dériver la valeur de l'attribut de jeton Security Token Service Google à partir d'un jeton externe. Pour chaque attribut de jeton Security Token Service Google, vous pouvez définir un mappage d'attributs, formaté comme suit :

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

Remplacez les éléments suivants :

  • TARGET_ATTRIBUTE est un attribut du jeton Google Security Token Service.
  • SOURCE_EXPRESSION est une expression CEL (Common Expression Language) qui transforme un ou plusieurs attributs des jetons émis par votre fournisseur d'identité externe.

La liste suivante fournit des exemples de mappage d'attributs :

  • Attribuez l'attribut d'assertion sub à google.subject :

    google.subject=assertion.sub

  • Concaténez plusieurs attributs d'assertion :

    google.subject="myprovider::" + assertion.aud + "::" + assertion.sub

  • Mapper un attribut d'assertion workload_id avec un nom, puis attribuer le résultat à un attribut personnalisé nommé attribute.my_display_name :

    attribute.my_display_name={
  "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
  "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
}[assertion.workload_id]

  • Utilisez les opérateurs et fonctions logiques CEL pour définir un attribut personnalisé nommé attribute.environment sur prod ou test, selon le nom de ressource Amazon (ARN) de l'identité :

    attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"

  • Utilisez la fonction extract pour renseigner un attribut personnalisé aws_role avec le nom du rôle supposé ou, si aucun rôle n'a été supposé, avec l'ARN de l'identité.

    attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

  • La fonction split divise une chaîne sur la valeur de séparateur fournie. Par exemple, pour extraire l'attribut username d'un attribut d'adresse e-mail en divisant sa valeur à l'aide de @, et en utilisant la première chaîne, utilisez le mappage d'attributs suivant : 

    attribute.username=assertion.email.split("@")[0]

  • La fonction join permet de joindre une liste de chaînes sur la base de la valeur de séparateur fournie. Par exemple, pour renseigner l'attribut personnalisé department en concaténant une liste de chaînes avec . comme séparateur, utilisez le mappage d'attributs suivant : 

    attribute.department=assertion.department.join(".")

Pour AWS, Google fournit des mappages par défaut, qui couvrent les scénarios les plus courants. Vous pouvez également fournir des mappages personnalisés.

Pour les fournisseurs OIDC, vous spécifiez les mappages. Pour créer un mappage, consultez la documentation du fournisseur afin d'obtenir la liste des attributs sur ses identifiants.

Pour en savoir plus, consultez la documentation de l'API concernant le [champ attributeMapping][attribute-mapping-field].

Conditions d'attribut

Une condition d'attribut est une expression CEL qui peut vérifier les attributs d'assertion et les attributs cibles. Si la condition d'attribut renvoie true pour un identifiant donné, celui-ci est accepté. Dans le cas contraire, l'identifiant est rejeté.

Vous pouvez utiliser une condition d'attribut pour limiter les identités qui peuvent s'authentifier à l'aide de votre pool d'identités de charge de travail.

Les conditions d'attribut sont utiles dans les scénarios suivants :

  • Si votre charge de travail exploite un fournisseur d'identité accessible au grand public, vous pouvez limiter l'accès de sorte que seules les identités que vous choisissez puissent accéder à votre pool d'identités de charge de travail.

  • Si vous faites appel à un fournisseur d'identité pour plusieurs plates-formes cloud, vous pouvez empêcher que les identifiants destinés à être utilisés avec une autre plate-forme soient utilisés avec Google Cloud, et inversement. Cela permet d'éviter le problème de "confused deputy".

La condition d'attribut du fournisseur de pool d'identités de charge de travail peut utiliser le mot clé assertion, qui fait référence à un mappage représentant l'identifiant d'authentification émis par le fournisseur. Vous pouvez utiliser la notation à points pour accéder aux valeurs du mappage. Par exemple, les identifiants AWS incluent une valeur arn, à laquelle vous pouvez accéder en tant que assertion.arn. En outre, la condition d'attribut peut utiliser n'importe quel attribut défini dans le mappage d'attributs du fournisseur.

L'exemple suivant n'autorise que les requêtes provenant d'identités associées à un rôle AWS spécifique :

attribute.aws_role == "ROLE_MAPPING"

Pour en savoir plus, consultez la documentation de l'API consacrée au champ attributeCondition.

Gestion des accès

Le flux d'échange de jetons renvoie un jeton d'accès fédéré Vous pouvez utiliser ce jeton d'accès fédéré pour accorder l'accès à votre charge de travail au nom des identités principales sur les ressources Google Cloud et obtenir un jeton d'accès OAuth 2.0 de courte durée.

Vous pouvez utiliser ce jeton d'accès pour accorder un accès IAM.

Nous vous recommandons d'utiliser la fédération d'identité de charge de travail pour fournir un accès directement à une ressource Google Cloud. Bien que la plupart des API Google Cloud soient compatibles avec la fédération d'identité de charge de travail, certaines API présentent des limites. Vous pouvez également utiliser l'emprunt d'identité du compte de service.

Le jeton d'accès de courte durée vous permet d'appeler les API Google Cloud auxquelles le compte de service ou la ressource a accès.

Accès direct aux ressources

Vous pouvez utiliser l'accès direct aux ressources pour accorder à votre identité externe l'accès directement à une ressource Google Cloud à l'aide de rôles spécifiques à la ressource.

Autre solution : emprunt d'identité d'un compte de service

Au lieu de fournir un accès direct aux ressources, vous pouvez utiliser l'emprunt d'identité du compte de service.

Vous devez attribuer le rôle Utilisateur Workload Identity (roles/iam.workloadIdentityUser) à votre compte de service.

Champs d'application et sécurité des comptes principaux

Vous accordez l'accès aux comptes principaux ou à leurs sous-ensembles à l'aide de types de comptes principaux.

Types de comptes principaux

Le tableau suivant explique comment définir des comptes principaux en tant qu'individus et groupes d'identités :

Identités Format d'identifiant
Identité unique principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Toutes les identités d'un groupe principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP_ID
Toutes les identités avec une valeur d'attribut spécifique principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE

Étapes suivantes