Fédération d'identité du personnel

Ce document décrit les concepts clés de la fédération d'identité de personnel.

Qu'est-ce que la fédération d'identité de personnel ?

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'IAM, afin que les utilisateurs puissent accéder aux services Google Cloud. Avec la fédération d'identité de personnel, 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 Cloud pour 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 d'identité de personnel avec n'importe quel fournisseur d'identité compatible avec OpenID Connect (OIDC) ou SAML 2.0, comme Azure Active Directory (Azure AD). Les services AD FS (Active Directory Federation Services), Okta et autres.

Pools d'identités de personnel

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'organisation Google Cloud. Pour cette raison, les pools sont disponibles pour tous les projets et dossiers au sein de l'organisation, à condition de disposer des autorisations IAM appropriées pour afficher le pool. Lors de la configuration initiale de la fédération d'identité de personnel pour votre organisation, vous fournissez un nom pour le pool. Dans les stratégies d'autorisation IAM, vous référencez le pool par son nom. Pour cette raison, nous vous recommandons de choisir un nom qui décrit clairement les identités contenues dans le pool.

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 fournisseur d'identité.

La fédération d'identité de personnel 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.

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

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

Mappages d'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 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 par Google 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 4 Ko.

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 à 100 caractères.

    • Si un utilisateur est associé à plus de 100 groupes, définissez un ensemble de groupes plus petit et n'incluez que ces groupes dans les assertions utilisées 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.

  • attribute.KEY (facultatif) : attribut défini par le client, présent dans le jeton de fournisseur d'identité d'un utilisateur. Vous pouvez utiliser ces attributs personnalisés pour définir votre stratégie d'autorisation dans une stratégie d'autorisation IAM. Par exemple, vous pouvez choisir de définir un attribut tel que le centre de coûts de l'utilisateur : attribute.costcenter = "1234". Cet attribut peut ensuite être utilisé dans les conditions IAM pour n'accorder l'accès qu'aux utilisateurs de ce centre de coûts.

    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".

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/*

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 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".

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

La fédération d'identité du personnel, 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 auxquels les utilisateurs du pool de personnel peuvent accéder sont compatibles avec VPC Service Controls. Pour en savoir plus, consultez la page Produits compatibles et limites 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 produits Google 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égoriesJuridique 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.

Étapes suivantes