À propos de la fédération d'identité de charge de travail de parc

Cette page décrit la fédération d'identité de charge de travail de parc, un mécanisme permettant d'authentifier les requêtes des charges de travail de parc auprès des API Google Cloud . Sur cette page, vous découvrirez l'uniformité des identités pour les charges de travail, le fonctionnement de la fédération d'identité de charge de travail pour un parc et les bonnes pratiques pour la gérer à grande échelle.

Cette page s'adresse aux administrateurs et opérateurs de plates-formes, ainsi qu'aux ingénieurs en sécurité qui souhaitent gérer plus efficacement l'autorisation des charges de travail à grande échelle. Pour en savoir plus sur les rôles utilisateur et les exemples de tâches que nous citons dans la documentation Google Cloud, consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire cette page, assurez-vous de maîtriser les concepts suivants :

À propos des identités de charge de travail fédérées dans Google Cloud

La fédération d'identité de charge de travail est une fonctionnalité Google Cloud qui permet aux charges de travail de vos clusters de s'authentifier auprès de Google Cloud sans que vous ayez besoin de télécharger, d'alterner manuellement ni de gérer les identifiants. Les charges de travail utilisent à la place des jetons de courte durée générés par Google Cloud.

Workload Identity Federation for GKE est une implémentation de la fédération d'identité de charge de travail spécifique à GKE qui fournit un pool d'identités de charge de travail géré par Google à l'échelle du projet, à partir duquel les applications exécutées dans les clusters GKE obtiennent des identités. La fédération d'identité de charge de travail du parc étend la fédération d'identité de charge de travail pour GKE à tous les clusters membres du parc, que les clusters se trouvent dans des projets différents ou en dehors de Google Cloud. Avec la fédération d'identité de charge de travail de parc, les clusters enregistrés pour lesquels la fédération d'identité de charge de travail est activée au niveau de leur appartenance au parc obtiennent des identités à l'aide d'un pool d'identités de charge de travail géré par Google à l'échelle du parc. Ce pool partagé vous permet de configurer l'authentification auprès des API Google Cloud et d'autres services sur l'ensemble de votre parc, même sur plusieurs projets.

La fédération d'identité de charge de travail pour parc peut également être utilisée par l'agent Connect sur certains types de clusters pour s'authentifier auprès de Google Cloud en cas d'appartenance à un parc. Elle est nécessaire pour utiliser certaines fonctionnalités GKE compatibles avec plusieurs projets, telles que Cloud Service Mesh.

À propos des pools d'identités de charge de travail

Un pool d'identités de charge de travail est une entité qui gère de manière centralisée les identités de vos applications. Lorsque vous activez la fédération d'identité de charge de travail pour GKE sur vos clusters, le projet de cluster obtient un pool d'identités de charge de travail géré par Google, dont le nom est fixe et spécifique au projet. Les applications de vos clusters obtiennent des identités du pool d'identités de charge de travail géré par Google pour authentifier les appels d'API Google Cloud . Le pool d'identités de charge de travail géré par Google utilise la syntaxe PROJECT_ID.svc.id.goog, où PROJECT_ID est l'ID du projet de cluster.

Avec la fédération d'identité de charge de travail de parc, le pool d'identités de charge de travail géré par Google du projet hôte du parc est également le pool d'identités de charge de travail pour tous les clusters que vous enregistrez dans le parc, que ces clusters se trouvent dans d'autres projets ou en dehors de Google Cloud. Chaque cluster du parc utilise le pool d'identités de charge de travail FLEET_HOST_PROJECT_ID.svc.id.goog, où FLEET_HOST_PROJECT_ID correspond à l'ID du projet hôte du parc.

Si vous utilisez des scopes d'équipe, vous pouvez éventuellement configurer un pool d'identités de charge de travail IAM autogéré pour que les clusters l'utilisent en plus du pool géré par Google. Ce pool autogéré permet de contrôler plus précisément les charges de travail qui obtiennent des identités spécifiques.

Chaque application de votre parc reçoit une identité fédérée distincte du pool d'identités de charge de travail du parc. Cette identité peut être utilisée par l'application pour s'authentifier auprès deGoogle Cloud et d'autres services que vous développez. Les applications obtiennent un identifiant principal que IAM peut reconnaître. Cet identifiant utilise la syntaxe suivante :

PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/SELECTOR

Cette syntaxe comporte les champs suivants :

  • PREFIX : principal ou principalSet, selon le type de ressource Kubernetes que vous sélectionnez dans le champ SÉLECTEUR.
  • FLEET_PROJECT_NUMBER : numéro du projet hôte du parc.

  • WORKLOAD_IDENTITY_POOL_NAME : pool d'identités de charge de travail pour votre parc. Cette valeur dépend du pool d'identités de charge de travail que vous configurez dans chaque cluster, comme suit :

    • Pool d'identités de charge de travail géré par Google : FLEET_HOST_PROJECT_ID.svc.id.goog

    • Pool d'identités de charge de travail autogéré (preview) : POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, où POOL_HOST_PROJECT_NUMBER est le numéro du projet dans lequel vous avez créé le pool d'identités de charge de travail autogéré.

  • SELECTOR : sélecteur de ressources. Pour obtenir la liste des sélecteurs acceptés, consultez la section Identifiants principaux acceptés. Par exemple, subject/ns/NAMESPACE/sa/SERVICEACCOUNT sélectionne un compte de service Kubernetes spécifique dans un espace de noms spécifique.

L'ensemble du parc partage un pool d'identités de charge de travail afin que vous puissiez accorder aux applications n'importe où dans le parc, y compris dans d'autres projets ou clouds, l'accès aux mêmes ressources sans avoir à gérer cet accès pour chaque cluster.

À propos de l'uniformité de l'identité

Comme les autres fonctionnalités compatibles avec les parcs, la fédération d'identité de charge de travail du parc repose sur le principe d'uniformité, qui consiste à traiter comme une même entité les objets Kubernetes portant le même nom et le même espace de noms dans différents clusters. Pour en savoir plus sur le principe général d'uniformité dans les parcs, consultez Uniformité.

Avec la fédération d'identité de charge de travail pour GKE à un seul projet, l'identité identique s'applique à toutes les entités qui partagent un identifiant de compte principal dans ce projet. Toutefois, avec la fédération d'identité de charge de travail du parc, cette uniformité d'identité s'applique implicitement à toutes les entités qui partagent un identifiant principal dans l'ensemble du parc, quel que soit le projet de cluster.

Prenons l'exemple d'une application avec un backend déployé sur plusieurs clusters dans le même parc. Si vous accordez un rôle à un identifiant principal qui sélectionne le compte de service Kubernetes default dans l'espace de noms Kubernetes backend, toutes les applications de cet espace de noms qui utilisent ce compte de service obtiennent le même accès.

Si votre parc n'exécute que des clusters dans le projet hôte du parc, les implications de l'identité sont les mêmes que pour la fédération d'identité de charge de travail pour GKE. Toutefois, si votre parc comporte des clusters qui s'exécutent dans d'autres projets ou en dehors deGoogle Cloud, cette identité implicite identique s'étend à tous les clusters enregistrés dans le parc.

Uniformité de l'identité dans les environnements mutualisés ou à confiance mixte

Par défaut, votre parc utilise le pool d'identités de charge de travail géré par Google du projet hôte du parc pour fournir des identités aux charges de travail du parc. Tous les clusters du projet hôte du parc, y compris les clusters autonomes qui ne sont pas enregistrés dans le parc, utilisent ce pool d'identités de charge de travail. Dans un environnement à confiance mixte où ces clusters autonomes exécutent des charges de travail qui ont un modèle de confiance différent, cette uniformisation implicite de l'identité peut entraîner un accès non souhaité.

Les parcs vous permettent de gérer ce modèle mutualisé à l'aide de niveaux d'accès d'équipe et d'espaces de noms de parc. Les niveaux d'accès d'équipe vous permettent de désigner des sous-ensembles de ressources de parc, comme des clusters, à utiliser par des équipes spécifiques de votre organisation. Les espaces de noms de parc vous permettent de définir des espaces de noms Kubernetes dans des niveaux d'accès spécifiques aux équipes. Ainsi, certaines équipes ne peuvent exécuter des charges de travail que dans les espaces de noms de leur niveau d'accès. Pour en savoir plus, consultez la présentation de la gestion des équipes de parc.

Si vous utilisez des portées d'équipe, vous pouvez atténuer les complexités liées à l'identité identique dans les parcs multitenants en configurant votre propre pool d'identités de charge de travail pour que des clusters spécifiques de votre parc l'utilisent à la place du pool d'identités de charge de travail géré par Google. Par conséquent, les identifiants principaux de ces charges de travail sont explicitement différents de ceux des clusters autonomes du projet. Cette uniformité explicite de l'identité permet aux administrateurs de mieux contrôler les limites dans lesquelles l'uniformité de l'identité s'applique.

Le modèle d'identité identique dans votre parc change comme suit, selon que vous utilisez uniquement le pool d'identités de charge de travail géré par Google ou que vous configurez un pool d'identités de charge de travail autogéré :

  • Uniformité implicite des identités : toutes les charges de travail d'un parc utilisent le pool d'identités de charge de travail géré par Google. Par conséquent, chaque charge de travail qui partage le même identifiant principal partage implicitement le même accès.

  • Uniformité explicite des identités (aperçu) : vous configurez un pool d'identités de charge de travail autogéré pour les périmètres d'équipe dans le parc. Le pool autogéré ne fournit des identités aux charges de travail que si vous configurez un cluster pour qu'il utilise le pool autogéré pour un espace de noms de parc spécifique. Les charges de travail qui s'exécutent dans d'autres espaces de noms et clusters Kubernetes ne peuvent pas utiliser le pool autogéré.

    Par conséquent, l'identité des charges de travail qui utilisent le pool autogéré est différente de celle des charges de travail qui ne peuvent utiliser que le pool d'identités de charge de travail géré par Google.

Quand utiliser les pools d'identités de charge de travail autogérés

Utilisez le pool d'identités de charge de travail géré par Google si chaque cluster présente un niveau de confiance similaire, dans lequel les mêmes entités déploient les mêmes applications. Par exemple, un parc spécifique à une équipe avec un cluster dans chaque région qui déploie une application répliquée dans chaque cluster.

Nous vous recommandons de configurer un pool d'identités de charge de travail autogéré pour votre parc dans les scénarios suivants :

  • Plusieurs niveaux de confiance dans le parc : vous exécutez des clusters comportant plusieurs niveaux de confiance. Par exemple, imaginons un scénario dans lequel les équipes financières et les équipes de développement de l'interface utilisateur ont des clusters dans le même parc. Un pool d'identités de charge de travail autogéré vous aide à séparer les droits d'accès pour chaque équipe par espace de noms de parc. Cela signifie que même l'administrateur de cluster du cluster de frontend ne peut pas obtenir d'identité dans l'espace de noms du parc, sauf s'il dispose d'autorisations explicites.
  • Plusieurs niveaux de confiance dans le projet : votre projet hôte de parc exécute des clusters autonomes qui peuvent ne pas avoir le même niveau de confiance que vos clusters de parc. Par défaut, ces clusters autonomes utilisent le pool d'identités de charge de travail géré par Google du projet hôte du parc. Vos clusters de parc utilisent également ce pool d'identités de charge de travail, quel que soit le projet de cluster de parc. La définition d'un pool d'identités de charge de travail autogéré pour le parc garantit que les droits d'accès au pool autogéré n'accordent pas involontairement l'accès aux clusters autonomes.
  • Bonnes pratiques pour les groupes d'équipe : vous utilisez déjà les fonctionnalités de gestion des équipes de parc et vous souhaitez mettre en œuvre les bonnes pratiques recommandées pour accorder l'accès aux charges de travail. La définition d'un pool d'identités de charge de travail autogéré vous permet d'accorder l'accès aux charges de travail dans un espace de noms de parc spécifique dans un champ d'application d'équipe sans accorder cet accès à d'autres champs d'application d'équipe qui exécutent des charges de travail dans les mêmes clusters.

Fonctionnement de la fédération d'identité de charge de travail de parc

Les sections suivantes décrivent le fonctionnement de la fédération d'identité de charge de travail du parc, y compris le flux des identifiants d'authentification et les identifiants principaux IAM compatibles.

Flux des identifiants

Pour permettre aux applications d'un espace de noms spécifique de s'authentifier à l'aide de la fédération d'identité de charge de travail du parc, procédez comme suit :

  1. Déployez un ConfigMap dans cet espace de noms contenant les informations suivantes :

    • Le pool d'identités de charge de travail et le fournisseur d'identité de votre cluster.
    • Chemin d'accès dans chaque pod sur lequel Kubernetes monte un jeton ServiceAccount. Ce jeton est un jeton Web JSON (JWT) signé.

    Ce ConfigMap sert de fichier d'identifiants par défaut de l'application (ADC) pour les charges de travail.

  2. Créez une stratégie d'autorisation IAM qui accorde l'accès à des ressourcesGoogle Cloud spécifiques à l'identifiant de compte principal du compte principal de vos clusters, tel qu'un compte de service dans l'espace de noms.

  3. Assurez-vous que votre charge de travail dans l'espace de noms présente les configurations suivantes dans la spécification du pod :

    • La variable d'environnement GOOGLE_APPLICATION_CREDENTIALS est définie sur le chemin d'accès au point de montage du ConfigMap dans le pod.
    • Un volume projeté contenant le jeton ServiceAccount et la ConfigMap que vous avez créée, installé dans le même chemin d'accès que celui que vous spécifiez dans la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS.
    • Installation de volume dans le conteneur qui fait référence au volume projeté.

Lorsque la charge de travail effectue un appel d'API Google Cloud , les étapes suivantes se produisent :

  1. Les bibliothèques d'authentification Google Cloud utilisent les identifiants par défaut de l'application (ADC) pour trouver les identifiants. L'ADC vérifie le chemin d'accès que vous avez spécifié dans la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS pour rechercher un jeton d'authentification.
  2. La bibliothèque d'authentification ADC utilise les données du ConfigMap pour échanger le jeton JWT ServiceAccount que vous avez installé sur le pod contre un jeton d'accès fédéré de courte durée provenant de Security Token Service, qui fait référence à l'identifiant principal de la charge de travail.
  3. Les ADC incluent le jeton d'accès fédéré dans la requête API.
  4. La stratégie d'autorisation IAM autorise l'identifiant du compte principal à effectuer l'opération demandée sur la ressource Google Cloud .

Identifiants de compte principal compatibles avec la fédération d'identité de charge de travail de parc

Le tableau suivant décrit les sélecteurs que vous pouvez utiliser dans les règles d'autorisation IAM pour faire référence aux comptes principaux dans les flottes :

Type d'identifiant de compte principal Syntaxe
Tous les pods qui utilisent un compte de service Kubernetes spécifique Sélectionner le compte de service par nom : 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Remplacez les éléments suivants :

  • PROJECT_NUMBER : identifiant numérique de votre projet. Pour obtenir le numéro de projet, consultez la section Identifier des projets.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • NAMESPACE : espace de noms Kubernetes.
  • SERVICEACCOUNT : nom du compte de service Kubernetes.
Sélectionner le compte de service par UID : 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Remplacez les éléments suivants :

  • PROJECT_NUMBER : identifiant numérique de votre projet. Pour obtenir le numéro de projet, consultez la section Identifier des projets.
  • PROJECT_ID : ID de votre projet Fleet.
  • SERVICEACCOUNT_UID : UID de l'objet ServiceAccount sur le serveur d'API.

Étapes suivantes