Avant de lire ce guide, vous devez vous familiariser avec les concepts décrits dans Utiliser Workload Identity avec un parc.
Pour connaître les bonnes pratiques concernant l'adoption d'autres fonctionnalités de parc, consultez la section Planifier les fonctionnalités de parc.
Parc et pools d'identités de projet
Pour comprendre pourquoi la fédération d'identité de charge de travail à l'échelle du parc nécessite une adoption minutieuse, en particulier lorsque vous travaillez avec des parcs multiprojets, examinons de plus près le fonctionnement de la fédération d'identité de charge de travail pour GKE et de la fédération d'identité de charge de travail au niveau du parc. Dans les deux cas, les charges de travail s'authentifient à l'aide de jetons de courte durée générés par les clusters, chaque cluster étant ajouté en tant que fournisseur d'identité à un pool d'identités de charge de travail spécial. Les charges de travail exécutées dans un espace de noms spécifique peuvent alors partager la même identité IAM sur différents clusters.
Voici ce qu'il se passe avec la fédération d'identité de charge de travail standard pour GKE lorsqu'elle est activée pour vos clusters. Notez que la fédération d'identité de charge de travail pour GKE est activée par défaut pour les clusters Autopilot.
- GKE crée un pool d'identités de charge de travail géré par Google dans le projet du cluster :
PROJECT_ID.svc.goog.id. - GKE ajoute les clusters en tant que fournisseurs d'identité du pool.
- Par conséquent, les charges de travail exécutées dans un espace de noms spécifique partagent la même identité IAM entre les différents clusters d'un projet. L'identité se présente sous la forme suivante :
serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME].
La fédération d'identité de charge de travail à l'échelle du parc est automatiquement activée lorsque vous ajoutez un cluster sur lequel la fédération d'identité de charge de travail pour GKE est activée à un parc, y compris les clusters Autopilot, les clusters standards avec la fonctionnalité explicitement activée et les clusters GKE situés en dehors de Google Cloud.
Voici ce qu'il se passe lorsqu'un utilisateur enregistre un cluster sur lequel la fédération d'identité de charge de travail pour GKE est activée dans un parc :
- Le pool d'identités de charge de travail
FLEET_PROJECT_ID.svc.goog.idgéré par Google pour l'ensemble du parc dans le projet hôte du parc est créé, s'il n'existe pas déjà. Il est identique au pool d'identités de charge de travail du projet pour le projet hôte du parc. - Le cluster est ajouté au pool en tant que fournisseur d'identité.
- Par conséquent, les charges de travail exécutées dans un espace de noms spécifique partagent la même identité IAM entre les différents clusters du parc. Nous appelons cela l'uniformité implicite des identités de charge de travail de parc. L'identité se présente sous la forme suivante :
serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]. Les charges de travail de parc dans différents projets peuvent ensuite appeler les API Google en utilisant la même identité pour l'authentification.
Comme cela le suggère, si le parc ne comprend que des clusters d'un même projet et qu'ils sont tous enregistrés dans le parc, le résultat est le même que si vous n'utilisiez que la fédération d'identité de charge de travail pour GKE sans parc : tous les clusters sont des fournisseurs d'identité dans le pool d'identités de charge de travail au niveau du projet, et les charges de travail utilisent les mêmes identités qu'elles utiliseraient avec la fédération d'identité de charge de travail pour GKE. Toutefois, lorsque le parc comporte des clusters membres dans plusieurs projets, la fédération d'identité de charge de travail du parc combine les pools d'identités par projet en un seul pool d'identités à l'échelle du parc, qui est hébergé dans le projet hôte du parc.
Comme vous le verrez dans les exemples suivants, certaines complexités peuvent se produire en cas de chevauchement partiel entre l'ensemble des clusters d'un projet et l'ensemble des clusters de ce projet qui sont membres d'un parc.
Scénario 1 : parc à projet unique avec tous les clusters enregistrés
Dans ce scénario, tous les clusters membres du parc se trouvent dans le projet hôte du parc, et tous les clusters de ce projet sont membres du parc.
Comme décrit dans la section précédente, l'utilisation de la fédération d'identité de charge de travail à l'échelle du parc dans ce scénario est identique à celle de la fédération d'identité de charge de travail standard pour GKE, et aucun risque supplémentaire n'est présent.
Scénario 2 : parc de projet unique avec seulement certains clusters enregistrés
Dans ce scénario, un parc contient deux clusters, tous deux situés dans le projet hôte de parc "Project 1". Le projet hôte de parc contient également un troisième cluster qui n'est pas membre du parc, et sur lequel la fédération d'identité de charge de travail pour GKE est activée.
Le service s'occupe des opérations suivantes :
- Les clusters 1, 2 et 3 sont ajoutés par GKE au pool d'identités de charge de travail du projet
project-1.svc.goog.id. - Les clusters 1 et 2 sont ajoutés par le parc au pool d'identités de charge de travail du parc, qui (comme il s'agit du projet hôte du parc) est également le pool d'identités de charge de travail du projet
project-1.svc.goog.id.
L'administrateur souhaite accorder des autorisations aux charges de travail s'exécutant dans un même espace de noms pour tous les clusters du parc. Il utilise serviceAccount:project-1.svc.goog.id[namespace/ksa] comme identité pour accorder l'accès. Cependant, les charges de travail de cet espace de noms situées sur le cluster 3, qui ne fait pas partie du parc, partagent désormais le même accès. En effet, le cluster 3 se trouve dans le pool d'identités de charge de travail du projet, qui est identique au pool d'identités de charge de travail du parc (car il s'agit du projet hôte du parc). En d'autres termes, l'administrateur peut vouloir accorder des autorisations uniquement aux clusters d'un parc, mais compte tenu de l'implémentation de la fédération d'identité de charge de travail pour les parcs, les clusters non associés à un parc peuvent également se voir attribuer un accès.
Atténuation possible
Une solution possible consiste à créer un projet dédié pour héberger le parc sans clusters. Cette solution est mise en œuvre par la stratégie d'organisation personnalisée sur l'API de conteneur. Cela permet de séparer clairement le domaine de confiance du pool d'identités de charge de travail du parc des domaines de confiance au niveau du projet GKE.
L'administrateur peut ensuite choisir le domaine de confiance approprié lorsqu'il accorde des autorisations aux charges de travail. Par exemple, il peut utiliser serviceAccount:project-0.svc.goog.id[namespace/ksa] pour accorder des autorisations sur l'intégralité du parc à une charge de travail associée à un espace de noms. Le cluster 3, qui n'est pas membre du parc, ne fait pas partie de ce pool d'identités de charge de travail dans cette configuration, et ne se voit donc pas accorder d'accès.
Cette solution fonctionne pour les clusters sur Google Cloud ainsi que pour les clusters associés.
Scénario 3 : parc multiprojet avec seulement certains clusters enregistrés
Dans ce scénario, un parc comprend des membres de deux projets, Project 1 et Project 2.
L'administrateur souhaite accorder des autorisations sur tous les clusters du projet 1 aux charges de travail s'exécutant dans un espace de noms, à l'aide de la fédération d'identité de charge de travail standard pour GKE. Toutefois, comme le cluster 4 est enregistré dans le parc et que le projet 1 est le projet hôte du parc, les charges de travail du cluster 4 dans le projet 2 bénéficient également des mêmes autorisations.
Atténuation possible
Comme dans le scénario précédent, une solution possible consiste à créer un projet hôte de parc dédié qui ne contient aucun cluster. Là encore, cela permet à l'administrateur de distinguer les identités du pool d'identités du parc et celles du pool d'identités de projet de chaque cluster lors de la configuration du contrôle des accès.
Scénario 4 : prise en compte de l'uniformité d'espace de noms
Les pools d'identités de charge de travail ne sont pas le seul point potentiel de confusion lors de l'utilisation de la fédération d'identité de charge de travail. Comme vous l'avez vu dans la section Planifier les fonctionnalités de parc, de nombreuses fonctionnalités de parc, y compris la fédération d'identité de charge de travail de parc, reposent sur l'hypothèse d'uniformité des espaces de noms pour simplifier la configuration et la gestion de l'ensemble du parc. Cela signifie que la fonctionnalité traite les espaces de noms qui portent le même nom et sont situés dans différents clusters membres du parc comme s'ils faisaient partie du même espace de noms. Dans cet exemple, un administrateur a accordé des autorisations aux charges de travail de l'espace de noms NS1 qui sont exécutées sur les clusters membres du parc (Cluster 1 et Cluster 2).
Cependant, un utilisateur a créé (accidentellement ou de manière malveillante) un espace de noms portant le même nom sur un autre cluster membre du parc. En raison de l'uniformité implicite des espaces de noms, les charges de travail de cet espace de noms obtiennent automatiquement les mêmes privilèges que les charges de travail NS1 légitimes dans Cluster 1 et Cluster 2.
Atténuation possible
Parmétrez les autorisations afin que seul un petit groupe de rôles approuvés puisse créer des espaces de noms dans les clusters.