Fédération des identités des employés

Ce document décrit les concepts clés de la fédération des identités des employés.

Qu'est-ce que la fédération des identités des employés ?

La fédération d'identité du personnel vous permet d'utiliser un fournisseur d'identité externe (IdP) pour authentifier et autoriser du personnel (un groupe d'utilisateurs tels que des employés, des partenaires et des sous-traitants) à l'aide d'Identity and Access Management (IAM), afin que les utilisateurs puissent accéder aux services Google Cloud . Avec la fédération des identités des employés, vous n'avez pas besoin de synchroniser les identités des utilisateurs de votre fournisseur d'identité existant avec les identités Google Cloud, comme vous le feriez avec Google Cloud Directory Sync (GCDS). La fédération d'identité du personnel étend les fonctionnalités d'identité de Google Cloudpour permettre l'authentification unique sans synchronisation et basée sur des attributs.

Une fois l'authentification des utilisateurs effectuée, les informations reçues du fournisseur d'identité sont utilisées pour déterminer le champ d'application de l'accès aux ressources Google Cloud .

Vous pouvez utiliser la fédération des identités des employés avec n'importe quel fournisseur d'identité compatible avec OpenID Connect (OIDC) ou SAML 2.0, comme Microsoft Entra ID, Active Directory Federation Services (AD FS), Okta et d'autres.

Pools d'identités d'employés

Les pools d'identités des employés vous permettent de gérer des groupes d'identités de collaborateurs et leur accès aux ressources Google Cloud .

Les pools vous permettent d'effectuer les opérations suivantes :

  • Regrouper les identités des utilisateurs, par exemple employees ou partners.
  • Accorder l'accès IAM à un pool entier ou à un sous-ensemble de ce dernier.
  • Fédérer les identités d'un ou plusieurs fournisseurs d'identité.
  • Définir des stratégies pour un groupe d'utilisateurs nécessitant des autorisations d'accès similaires.
  • Spécifier les informations de configuration spécifiques au fournisseur d'identité, y compris le mappage d'attributs et les conditions d'attributs.
  • Activer l'accès à Google Cloud CLI et à l'API pour les identités tierces.
  • Journaliser l'accès des utilisateurs d'un pool à Cloud Audit Logs, en incluant l'ID de pool.

Vous pouvez créer plusieurs pools. Pour obtenir un exemple décrivant une telle approche, consultez la section Exemple : multiples pools d'identités de personnel.

Les pools sont configurés au niveau de l'organisationGoogle Cloud , ce qui implique les considérations suivantes :

  • Lors de la configuration initiale de la fédération d'identité de personnel pour votre organisation, fournissez un nom unique pour le pool. Le nom doit être unique pour tous les pools de l'organisation et doit décrire clairement les identités qu'il contient.
  • Si vous disposez des autorisations IAM appropriées pour afficher le pool, vous pouvez le référencer par son nom dans tous les projets et dossiers de l'organisation.

Fournisseurs de pools d'identités de personnel

Un fournisseur de pools d'identités de personnel est une entité qui décrit une relation entre votre organisation Google Cloud et votre IdP.

La fédération des identités des employés applique la spécification OAuth 2.0 Token Exchange (RFC 8693). Vous fournissez un identifiant provenant de votre fournisseur d'identité externe à Security Token Service, qui vérifie l'identité dans l'identifiant, puis renvoie un jeton d'accès Google Cloud de courte durée en échange.

Types de flux OIDC

Pour les fournisseurs OIDC, la fédération des identités des employés est compatible avec le flux avec code d'autorisation et le flux implicite. Le flux avec code d'autorisation est considéré comme le plus sécurisé, car les jetons sont renvoyés par le fournisseur d'identité dans une transaction backend sécurisée et distincte, directement du fournisseur d'identité vers Google Cloud, une fois les utilisateurs authentifiés. Par conséquent, les transactions de flux de code peuvent récupérer des jetons de n'importe quelle taille, ce qui vous permet d'avoir plus de revendications à utiliser pour le mappage d'attributs et la condition d'attribut. En comparaison, dans le flux implicite, le jeton d'ID est renvoyé par le fournisseur d'identité au navigateur. Les jetons sont soumis à des limites de taille d'URL de navigateur individuelles.

Google Cloud Console de fédération d'identité de personnel

Les utilisateurs d'un pool d'identités de personnel peuvent accéder à la console de fédération d'identité de personnel Google Cloud , également appelée console (fédération). La console fournit à ces utilisateurs un accès d'UI auxGoogle Cloud produits compatibles avec la fédération des identités des employés.

Attributs

Votre fournisseur d'identité fournit des attributs, désignés par certains fournisseurs d'identité sous l'appellation revendications. Les attributs contiennent des informations sur vos utilisateurs. Vous pouvez utiliser ces attributs dans les mappages d'attributs et les conditions d'attributs.

Mappages d'attributs

Vous pouvez mapper ces attributs pour les utiliser dans Google Cloud en utilisant le CEL (Common Expression Language).

Cette section décrit l'ensemble des attributs obligatoires et facultatifs fournis parGoogle Cloud .

Vous pouvez également définir des attributs personnalisés dans votre fournisseur d'identité, qui peuvent ensuite être utilisés par des produits Google Cloud spécifiques, par exemple dans les stratégies d'autorisation IAM.

La taille maximale des mappages d'attributs est de 16 Ko. Si la taille des mappages d'attributs dépasse la limite de 16 Ko, la tentative de connexion échoue.

Les attributs sont les suivants :

  • google.subject (obligatoire) : identifiant unique de l'utilisateur authentifié. Il s'agit souvent de l'assertion de sujet du JWT, car les journaux d'audit Cloud enregistrent le contenu de ce champ en tant que compte principal. Ce champ vous permet de configurer IAM pour les décisions d'autorisation. Nous vous recommandons de ne pas utiliser de valeur modifiable, car si vous modifiez la valeur figurant dans l'annuaire des utilisateurs de votre fournisseur d'identité, l'utilisateur perdra l'accès.

    La valeur ne doit pas dépasser 127 octets.

  • google.groups (facultatif) : collection de groupes dont l'utilisateur authentifié est membre. Vous pouvez configurer une expression logique à l'aide d'un sous-ensemble de CEL qui génère un tableau de chaînes. Vous pouvez également utiliser ce champ pour configurer IAM pour les décisions d'autorisation. Les limites pour google.groups sont les suivantes :

    • Nous vous recommandons de limiter le nom de groupe à 40 caractères.

    • Si un utilisateur appartient à plus de 400 groupes, sa tentative de connexion échouera. Pour éviter cela, vous devez définir un ensemble de groupes plus petit dans l'assertion et ne mapper que les groupes utilisés pour fédérer l'utilisateur avec Google Cloud.

    • Si vous utilisez cet attribut pour accorder l'accès dans IAM, tous les membres des groupes mappés disposent d'un accès. Par conséquent, nous vous recommandons de vous assurer que seuls les utilisateurs autorisés de votre organisation peuvent modifier l'appartenance aux groupes mappés.

  • google.display_name (facultatif) : attribut utilisé pour définir le nom de l'utilisateur connecté dans la console Google Cloud . Cet attribut ne peut être utilisé ni dans les stratégies d'autorisation IAM, ni dans la condition d'attribut.

    La valeur ne doit pas dépasser 100 octets.

  • google.profile_photo (facultatif) : URL de la photo miniature de l'utilisateur. Nous recommandons d'utiliser une photo de 400 x 400 pixels. Lorsque cet attribut est défini, l'image est visible en tant que photo de profil de l'utilisateur dans la console Google Cloud . Si cette valeur n'est pas définie ou ne peut pas être récupérée, une icône d'utilisateur générique s'affiche à la place. Cet attribut ne peut être utilisé ni dans les stratégies d'autorisation IAM, ni dans la condition d'attribut.

  • google.posix_username (facultatif) : chaîne d'utilisateur unique compatible avec POSIX utilisée pour les éléments suivants :

    Cet attribut ne peut pas être utilisé dans les stratégies d'autorisation IAM, ni dans la condition d'attribut. La longueur ne doit pas dépasser 32 caractères.

  • google.email (facultatif) : attribut utilisé pour mapper les adresses e-mail des utilisateurs fédérés connectés depuis l'IdP aux produits que vous intégrez à l'aide de l'intégration du client OAuth de la fédération d'identité des employés. Cet attribut ne peut pas être utilisé dans les stratégies d'autorisation IAM, ni dans la condition d'attribut.

    Par exemple, pour mapper les adresses e-mail d'Okta à l'aide du protocole OIDC, incluez google.email=assertion.email dans votre mappage d'attributs.

    Voici quelques exemples de produits Google Cloud compatibles avec l'intégration de clients OAuth :

  • attribute.KEY (facultatif) : attribut défini par un fournisseur d'identité externe, présent dans le jeton de fournisseur d'identité d'un utilisateur. Vous pouvez utiliser l'attribut personnalisé pour définir votre stratégie d'autorisation dans une stratégie d'autorisation IAM.

    Par exemple, dans votre IdP, vous pouvez choisir de définir un attribut tel que le centre de coûts de l'utilisateur comme costcenter = "1234", puis faire référence au principal de la manière suivante :

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234

    Une fois que vous avez accordé l'accès aux ressources Google Cloud à cet identifiant principal, toutes les identités configurées dans l'IdP avec l'attribut costcenter défini sur 1234 ont accès aux ressources.

    Vous pouvez configurer jusqu'à 50 règles de mappage d'attributs personnalisés. La taille maximale de chaque règle est de 2048 caractères.

    Bien qu'aucune restriction ne s'applique aux attributs que vous pouvez mapper ici, nous vous recommandons vivement de choisir des attributs dont les valeurs sont stables. Par exemple, un attribut tel que attribute.job_description peut changer pour de nombreuses raisons (telles que l'amélioration de sa lisibilité). Envisagez plutôt d'utiliser attribute.role. Les modifications appliquées à cette dernière option indiquent une modification de l'attribution de responsabilité et sont alignées avec les modifications du niveau d'accès accordé à l'utilisateur.

Vous pouvez transformer les valeurs d'attribut à l'aide des fonctions CEL standards. Vous pouvez également utiliser les fonctions personnalisées suivantes :

  • La fonction split permet de scinder une chaîne au niveau de 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(".")

Conditions d'attribut

Les conditions d'attribut sont des expressions CEL facultatives qui vous permettent de définir des contraintes sur les attributs d'identité acceptés par Google Cloud .

Les avantages des conditions d'attribut sont les suivants :

  • Vous pouvez utiliser des conditions d'attribut pour n'autoriser qu'un sous-ensemble d'identités externes à s'authentifier auprès de votre projet Google Cloud . Par exemple, vous pouvez autoriser uniquement les identités qui appartiennent à une équipe spécifique à se connecter, en particulier si vous utilisez un fournisseur d'identité public. Pour un autre exemple, vous souhaiterez peut-être autoriser votre équipe de comptabilité à se connecter, mais pas votre équipe d'ingénieurs.
  • Les conditions d'attribut vous permettent d'empêcher l'utilisation d'identifiants destinés à une autre plate-forme sur Google Cloud, et inversement. Cela permet d'éviter le problème de "confused deputy".

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 des identités des employés ne gère pas d'annuaire de comptes utilisateur. Elle implémente 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 censés identifier le même utilisateur. Pour déterminer quel IdP a émis un jeton, la fédération des identités des employés inspecte et vérifie l'URL de l'émetteur du jeton.

Les IdP mutualisés, 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 de 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 des identités des employés 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. Si votre IdP mutualisé ne comporte qu'une seule URL d'émetteur, nous vous recommandons d'utiliser des conditions d'attribut pour vous assurer que l'accès est limité au bon locataire.

Représenter les utilisateurs de pools de personnel dans les stratégies IAM

Le tableau suivant présente les identifiants principaux utilisables pour attribuer des rôles à un seul utilisateur, à un groupe d'utilisateurs, à des utilisateurs porteurs d'une revendication spécifique ou à tous les utilisateurs d'un pool de personnel.

Identités Format d'identifiant
Identité unique d'un pool d'identités de personnel principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Toutes les identités de personnel d'un groupe principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Toutes les identités de personnel porteuses d'une valeur d'attribut spécifique principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Toutes les identités d'un pool d'identités de personnel principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Pour obtenir la liste complète des identifiants principaux, consultez Identifiants principaux.

Journaux d'audit détaillés

La journalisation d'audit détaillée est une fonctionnalité de la fédération d'identité des employés qui enregistre les attributs reçus de votre IdP dans Cloud Audit Logs.

Vous pouvez activer la journalisation d'audit détaillée lorsque vous créez votre fournisseur de pool d'identités de personnel.

Pour savoir comment résoudre les erreurs de mappage d'attributs à l'aide de journaux d'audit détaillés, consultez Erreurs générales de mappage d'attributs.

Clés Web JSON

Le fournisseur de pools d'employés peut accéder aux clés Web JSON (JWK) spécifiées par votre IdP dans le champ jwks_uri du document /.well-known/openid-configuration. Si votre fournisseur OIDC ne fournit pas ces informations, ou si votre émetteur n'est pas accessible publiquement, vous pouvez importer manuellement les JWK lors de la création ou de la mise à jour du fournisseur OIDC.

Restreindre l'accès entre organisations

Les comptes principaux d'un pool d'identités des employés ne peuvent pas accéder directement aux ressources extérieures à l'organisation à laquelle ils appartiennent. Toutefois, si un compte principal est autorisé à emprunter l'identité d'un compte de service au sein de l'organisation, cette contrainte peut être contournée, car les comptes de service ne sont pas restreints de la même manière.

Projet utilisateur des pools de personnel

La plupart des API Google Cloud attribuent la facturation et l'utilisation de quotas au projet qui contient la ressource à laquelle votre requête API accède. Ces API sont appelées des API basées sur des ressources. Certaines API Google Cloud facturent le projet associé au client. Ces API sont appelées des API basées sur le client. Le projet utilisé pour la facturation et les quotas est appelé projet de quota.

Lorsque vous créez un fichier de configuration pour la fédération des identités des employés, vous spécifiez un projet utilisateur pour les pools d'employés. Ce projet permet d'identifier votre application auprès des API Google qu'il appelle. Le projet utilisateur pour les pools d'employés est également utilisé comme projet de quota par défaut pour les API basées sur le client, sauf si vous utilisez gcloud CLI pour lancer la requête API. Vous devez disposer de l'autorisation serviceusage.services.use, incluse dans le rôle Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer), pour le projet que vous spécifiez.

Pour en savoir plus sur le projet de quota, les API basées sur les ressources et les API basées sur le client, consultez la page Présentation des projets de quota.

Exemple : multiples pools d'identités des employés

Cette section contient un exemple illustrant l'utilisation typique de pools multiples.

Vous pouvez créer un pool pour les employés et un autre pour les partenaires. Les multinationales peuvent créer des pools distincts pour différents secteurs ou services au sein de leur organisation. Les pools permettent une gestion distribuée dans laquelle différents groupes peuvent gérer indépendamment leur pool spécifique, les rôles étant exclusivement attribués aux identités contenues dans le pool.

Par exemple, supposons qu'une entreprise nommée "Enterprise Example Organization" fasse appel à une autre entreprise nommée "Partner Example Organization Inc" pour fournir des services DevOps GKE (Google Kubernetes Engine). Pour que le personnel de "Partner Example Organization" puisse fournir les services, les employés doivent être autorisés à accéder à Google Kubernetes Engine (GKE) et à d'autres ressources Google Cloud dans l'organisation de "Enterprise Example Organization". L'organisation "Enterprise Example" dispose déjà d'un pool d'identités des employés appelé enterprise-example-organization-employees.

Pour permettre à "Partner Example Organization" de gérer l'accès aux ressources de "Enterprise Example Organization", cette dernière crée un pool de personnel distinct pour les utilisateurs du personnel de "Partner Example Organization" afin d'autoriser l'accès. "Enterprise Example Organization" fournit ensuite le pool de personnel à un administrateur "Partner Example Organization". L'administrateur "Partner Example Organization" utilise son propre fournisseur d'identité pour accorder l'accès à son personnel.

Pour ce faire, l'administrateur "Partner Example Organization" effectue les tâches suivantes :

  1. Créer une identité telle que partner-organization-admin@example.com pour l'administrateur "Partner Example Organization" dans le fournisseur d'identité de "Enterprise Example Organization", qui est déjà configuré dans le pool appelé enterprise-example-organization-employees.

  2. Créez un nouveau pool d'employés nommé example-organization-partner.

  3. Créer la stratégie d'autorisation suivante pour le pool example-organization-partner :

    {
  "bindings": [
    {
      "role": "roles/iam.workforcePoolEditor",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
      ]
    }
  ]
}

  4. Accorder des rôles au pool example-organization-partner pour les ressources auxquelles il doit accéder dans l'organisation de "Enterprise Example Organization".

L'administrateur "Partner Example Organization" peut maintenant configurer le pool example-organization-partner pour se connecter à son fournisseur d'identité. Il peut ensuite autoriser le personnel de "Partner Example Organization" à se connecter avec les identifiants de fournisseur d'identité de "Partner Example Organization". Une fois connectés, les utilisateurs du personnel de "Partner Example Organization" peuvent accéder aux ressources Google Cloud , dans la limite des règles définies par "Enterprise Example Organization".

Gestion des accès simplifiée

Dans les grandes entreprises, les administrateurs informatiques créent souvent des groupes de sécurité dans le cadre d'un modèle de contrôle des accès recommandé. Les groupes de sécurité régissent l'accès aux ressources internes. De plus, les entreprises créent souvent des groupes supplémentaires pour les employés et d'autres groupes pour les partenaires afin d'étendre ce modèle de contrôle des accès aux ressources cloud. Cela peut entraîner une prolifération de groupes profondément imbriqués qui peuvent devenir très difficiles à gérer.

Votre organisation peut également appliquer des règles limitant le nombre de groupes qu'il est possible de créer, afin de maintenir une hiérarchie d'annuaire d'utilisateurs raisonnablement plate. Une meilleure solution pour éviter les erreurs de configuration de stratégies IAM et limiter la prolifération des groupes consiste à utiliser plusieurs pools pour créer une séparation plus large entre les utilisateurs des différentes unités organisationnelles et commerciales, et des organisations partenaires. Vous pouvez ensuite référencer ces pools et les groupes qu'ils contiennent pour définir des stratégies IAM (consultez les exemples présentés dans l'étape de configuration IAM).

Limites de VPC Service Controls

Les fonctionnalités d'administration de la fédération d'identité du personnel, y compris les API de configuration de pool de personnel et les API Security Token Service, ne sont pas compatibles avec VPC Service Controls. Toutefois,les produits Google Cloud compatibles à la fois avec la fédération d'identité du personnel et VPC Service Controls fonctionnent comme indiqué dans la documentation et sont soumis aux vérifications des règles de VPC Service Controls. De plus, vous pouvez utiliser des identités tierces telles que des utilisateurs de pools d'identités de personnel et des identités de charge de travail dans les règles d'entrée ou de sortie de VPC Service Controls.

Fédération des identités des employés et contacts essentiels

Pour recevoir des informations importantes sur les modifications concernant votre organisation ou vos produitsGoogle Cloud , vous devez fournir des contacts essentiels lorsque vous utilisez la fédération des identités des employés. Les utilisateurs Cloud Identity peuvent être contactés via leur adresse e-mail Cloud Identity, mais les utilisateurs de la fédération des identités des employés sont contactés via la section Contacts essentiels.

Lorsque vous utilisez la console Google Cloud pour créer ou gérer des pools d'identités de personnel, une bannière s'affiche et vous invite à configurer un contact essentiel dans les catégories Juridique et Suspension. Vous pouvez également définir un contact dans la catégorie Tous si vous n'avez pas de contacts distincts. Renseigner les contacts demandés entraîne la suppression de la bannière.

Étape suivante