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

Cette page décrit la fédération d'identités 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 en apprendrez davantage sur l'identité identique pour les charges de travail, le fonctionnement de la fédération d'identités de charge de travail pour un parc et les bonnes pratiques à suivre pour la gérer à grande échelle.

Cette page s'adresse aux administrateurs et opérateurs de plate-forme, 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 la section Rôles utilisateur et tâches courantes de GKE Enterprise.

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

• Stratégies d'autorisation IAM (Identity and Access Management)
• Fonctionnement des parcs
• Gestion de l'équipe de parc
• Comptes de service Kubernetes
• Volumes projetés pour Kubernetes

À 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 n'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é de charge de travail géré par Google à l'échelle du projet, à partir duquel les applications exécutées dans des clusters GKE obtiennent des identités. La fédération d'identité de charge de travail pour 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.

L'agent Connect peut également utiliser la fédération d'identité de charge de travail pour parc sur certains types de clusters pour s'authentifier auprès de Google Cloud en tant que membre d'un parc. Il est nécessaire d'utiliser certaines fonctionnalités de GKE Enterprise 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 reçoit un pool d'identités de charge de travail géré par Google qui porte un nom fixe spécifique au projet. Les applications de vos clusters obtiennent des identités à partir 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 a la syntaxe PROJECT_ID.svc.id.goog, où PROJECT_ID est l'ID de projet du 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 de 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 est l'ID de projet du projet hôte du parc.

Si vous utilisez des champs d'application d'équipe, vous pouvez éventuellement configurer un pool d'identités de charge de travail IAM autogéré que les clusters peuvent utiliser en plus du pool géré par Google. Ce pool autogéré offre un contrôle plus explicite sur les charges de travail qui reçoivent 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, qu'elle peut utiliser pour s'authentifier auprès deGoogle Cloud et d'autres services que vous développez. Les applications reçoivent 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, en fonction du type de ressource Kubernetes que vous sélectionnez dans le champ SELECTOR (SÉLECTIONNEUR).
• FLEET_PROJECT_NUMBER: numéro du projet hôte du parc.

• WORKLOAD_IDENTITY_POOL_NAME: le pool d'identités de charge de travail de 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 charges de travail géré par Google : FLEET_HOST_PROJECT_ID.svc.id.goog

  • Pool d'identités de charge de travail autogéré (version 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 ServiceAccount Kubernetes spécifique dans un espace de noms spécifique.

L'ensemble du parc partage un pool d'identités de charge de travail de parc afin que vous puissiez accorder aux applications de n'importe quel endroit du 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 pour 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é, selon lequel les objets Kubernetes portant le même nom et le même espace de noms dans différents clusters sont traités comme une même entité. Pour en savoir plus sur le principe général d'uniformité dans les parcs, consultez la section Uniformité.

Avec la fédération d'identité de charge de travail pour GKE pour 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 de parc, cette uniformité de l'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 de 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 s'étend à tous les clusters enregistrés du parc.

Uniformité de l'identité dans les environnements multi-tenants ou de 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 de l'ensemble 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 de confiance mixte où ces clusters autonomes exécutent des charges de travail qui ont un modèle de confiance différent, cette identité implicite peut entraîner un accès non intentionnel.

Les parcs vous permettent de gérer ce modèle multi-tenant à l'aide de champs d'application 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 d'équipe spécifiques, de sorte que certaines équipes ne puissent 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 la complexité de l'identité dans les parcs multi-tenants en configurant votre propre pool d'identités de charge de travail pour les clusters spécifiques de votre parc à utiliser à 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 des identifiants principaux des clusters autonomes du projet. Cette identité identique explicite permet aux administrateurs de mieux contrôler les limites dans lesquelles l'identité identique s'applique.

Le modèle d'identité identique de votre parc change comme suit, selon que vous n'utilisez que 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é:

• Identité implicite: 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é des identités explicite (version preview): vous configurez un pool d'identités de charge de travail autogéré pour les portées 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 exécutées 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 des 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 flotte dans les scénarios suivants:

• Plusieurs niveaux de confiance dans le parc: vous exécutez des clusters qui comportent plusieurs niveaux de confiance. Par exemple, imaginons un scénario dans lequel les équipes financières et les équipes de développement frontal ont des clusters dans le même parc. Un pool d'identités de charge de travail autogéré vous permet de séparer les autorisations d'accès de chaque équipe par espace de noms de flotte. Cela signifie que même l'administrateur du 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 ne peuvent 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. Définir un pool d'identités de charge de travail autogéré pour le parc garantit que les autorisations d'accès au pool autogéré n'accordent pas accidentellement l'accès aux clusters autonomes.
• Bonnes pratiques pour les champs d'application d'équipe: vous utilisez déjà les fonctionnalités de gestion d'équipe de parc et souhaitez mettre en œuvre les bonnes pratiques recommandées pour accorder l'accès aux charges de travail. Configurer un pool d'identités de charge de travail autogéré vous permet d'accorder un 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 de votre parc, y compris le flux d'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 dans chaque pod sur lequel Kubernetes monte un jeton de compte de service. 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 de votre cluster, comme 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 définie sur le chemin d'installation du ConfigMap dans le pod.
   • Volume projeté contenant le jeton ServiceAccount et le ConfigMap que vous avez créés, installé dans le même chemin 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é éphémère du service de jetons de sécurité qui fait référence à l'identifiant principal de la charge de travail.
3. L'ADC inclut le jeton d'accès fédéré avec la requête API.
4. La stratégie d'autorisation IAM autorise l'identifiant 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 stratégies d'autorisation IAM pour référencer des comptes principaux dans des flottes:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Étapes suivantes

• Authentifier les charges de travail de flotte de confiance partagée auprès des Google Cloud API
• Authentifier les charges de travail de parcs de confiance mixte auprès des Google Cloud API
• Bonnes pratiques pour utiliser la fédération d'identité de charge de travail de parc