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

La fédération des identités des employés permet aux utilisateurs de votre fournisseur d'identité (IdP) externe d'utiliser l'authentification unique (SSO) pour accéder aux ressources Google Cloud .

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

La fédération des identités des employés vous permet d'utiliser votre fournisseur d'identité externe (IdP) pour authentifier votre personnel (utilisateurs et groupes d'utilisateurs tels que des employés, des partenaires et des sous-traitants). Vos utilisateurs peuvent ensuite accéder à Google Cloud à l'aide de l'authentification unique via votre fournisseur d'identité. Vous pouvez utiliser des règles Identity and Access Management (IAM) pour autoriser vos utilisateurs à accéder aux services Google Cloud .

Fédération et synchronisation

La fédération des identités des employés fédère les identités de votre IdP. Elle ne stocke donc pas les comptes utilisateur dans Google Cloud. C'est pourquoi la fédération d'identité de personnel est sans synchronisation. Cela signifie que vous n'avez pas besoin d'utiliser d'outils pour synchroniser les identités utilisateur de votre IdP avec les identités gérées par Google qui nécessitent des comptes Google. Par exemple, en utilisant la fédération d'identité de personnel, vous n'avez pas besoin d'utiliser Google Cloud Directory Sync (GCDS) de Cloud Identity.

Fédération d'identité de personnel et fédération d'identité de charge de travail

La fédération d'identité de personnel fédère les identités des utilisateurs, tandis que la fédération d'identité de charge de travail fédère les identités de charge de travail.

Pour en savoir plus, consultez Fédération d'identité de charge de travail.

Accès basé sur des attributs

La fédération des identités des employés étend les fonctionnalités d'identité de Google Cloudpour permettre l'accès basé sur des attributs. Dans certains IdP, les attributs sont également appelés revendications ou assertions.

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

Protocoles compatibles

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.

Concepts clés

Cette section décrit les concepts clés de la fédération des identités des employés.

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 entraîne 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.

Compatibilité SCIM

Si votre IdP est compatible avec le System for Cross-domain Identity Management (SCIM), vous pouvez le configurer pour provisionner et gérer des groupes dans Google Cloud.

Les locataires SCIM de la fédération d'identité de personnel sont compatibles avec le partage dans Gemini Enterprise. Une fois que vous avez configuré les locataires SCIM dans votre application IdP et dans la fédération d'identité de personnel, les utilisateurs de Gemini Enterprise peuvent partager des notebooks NotebookLM avec un groupe en utilisant le nom du groupe au lieu de son ID d'objet (UUID). Pour en savoir plus sur le partage de notebooks avec des groupes, consultez Partager un notebook avec un groupe.

Lorsque vous utilisez la compatibilité SCIM avec la fédération d'identité de personnel, les points suivants doivent être pris en compte :

  • Vous devez configurer un pool et un fournisseur d'identités de personnel avant de configurer un locataire SCIM.
  • Chaque pool d'identités de personnel n'est compatible qu'avec un seul locataire SCIM. Pour configurer un nouveau locataire SCIM dans le même pool d'identités de personnel, vous devez d'abord supprimer celui qui existe déjà. Lorsque vous supprimez un locataire SCIM, vous avez deux options :
    • Suppression réversible (par défaut) : la suppression d'un locataire SCIM lance une période de suppression réversible de 30 jours. Pendant cette période, le locataire est masqué et ne peut pas être utilisé. Vous ne pouvez pas non plus créer de locataire SCIM dans le même pool d'identités de personnel.
    • Suppression définitive : pour supprimer définitivement et immédiatement un locataire SCIM, utilisez l'option --hard-delete avec la commande de suppression. Cette action est irréversible et vous permet de créer un locataire SCIM dans le même pool d'identités des employés immédiatement après la suppression.
    Vous pouvez également créer un pool d'identités de personnel et un locataire SCIM, ou utiliser un pool d'identités de personnel qui n'a pas encore été configuré avec un locataire SCIM.
  • Lorsque vous utilisez SCIM, vous mappez les attributs dans le fournisseur de pool d'identités des employés et dans le locataire SCIM. L'attribut `google.subject` doit faire référence de manière unique aux mêmes identités. Vous spécifiez `google.subject` dans le fournisseur de pool d'identités de personnel à l'aide du flag --attribute-mapping et dans le locataire SCIM à l'aide du flag --claim-mapping. Les valeurs d'identité non uniques mappées de cette manière peuvent entraîner le traitement de différentes identités dans votre fournisseur d'identité comme une seule et même identité dans Google Cloud. Par conséquent, l'accès accordé à une identité d'utilisateur ou de groupe peut également être appliqué à d'autres identités. De plus, la révocation de l'accès pour une identité peut ne pas le révoquer pour toutes les identités, ce qui fait que certaines identités conservent l'accès.
  • Pour utiliser SCIM afin de mapper des groupes, définissez `--scim-usage=enabled-for-groups`. Lorsque vous mappez des groupes à l'aide de SCIM, tout mappage de groupe défini dans le fournisseur de pool d'identités des employés est ignoré. Lorsqu'il s'agit de groupes gérés par SCIM, l'attribut mappé est "google.group", et non "google.groups". "google.groups" ne fait référence qu'aux groupes mappés aux jetons.
  • Lorsque vous utilisez SCIM, les attributs basés sur des jetons qui sont mappés avec `--attribute-mapping` peuvent toujours être utilisés pour l'authentification et dans les identifiants principaux.
  • Pour la configuration de Microsoft Entra ID, vous ne devez pas utiliser les indicateurs --extended-attributes lorsque vous créez le fournisseur de pools d'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 le fournisseur d'identité 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'attributcostcenterdéfini sur1234ont 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". #### Conditions d'attribut pour les IdP 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, vous devez utiliser des conditions d'attribut pour vous assurer que l'accès est limité au bon locataire.

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.

Identifiants de comptes principaux pour les stratégies IAM

Le tableau suivant présente les identifiants principaux utilisables pour attribuer des rôles à des utilisateurs individuels et à des groupes d'utilisateurs.

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 d'employés d'un groupe principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Toutes les identités d'employés 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 d'employés principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

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

Autres points à noter

Cette section décrit d'autres points à prendre en compte lorsque vous utilisez la fédération d'identité de personnel.

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 dédié à la facturation et à l'utilisation de quotas est appelé le 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".

Bonnes pratiques concernant les groupes de sécurité

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 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 VPC Service Controls. Vous pouvez également utiliser des identités tierces telles que les utilisateurs de pools d'employés et les 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