Réduire les risques d'uniformité de l'identité dans les parcs mutualisés

Cette page fournit des bonnes pratiques pour configurer et utiliser la fédération d'identité de charge de travail de parc, une fonctionnalité de parc qui vous permet de configurer de manière centralisée l'authentification des applications auprès des Google Cloud API dans tous les projets. Pour connaître les bonnes pratiques concernant l'adoption d'autres fonctionnalités de parc, consultez la section Planifier les fonctionnalités de parc.

Cette page s'adresse aux administrateurs et opérateurs de plate-forme, ainsi qu'aux ingénieurs en sécurité qui souhaitent minimiser les risques associés à l'uniformité des identités dans les parcs.

Avant de lire cette page, assurez-vous de connaître les concepts présentés dans À propos de la fédération d'identité de charge de travail de parc.

Terminologie

Cette page utilise la terminologie suivante :

  • Workload Identity Federation for GKE : fonctionnalité qui fournit des identités aux charges de travail GKE dans un seul projet Google Cloud .
  • Fédération d'identité de charge de travail de parc : fonctionnalité qui étend Workload Identity Federation for GKE aux charges de travail de l'ensemble du parc, y compris en dehors et dans plusieurs projets. Google Cloud
  • Pool d'identités de charge de travail : entité qui fournit des identités aux charges de travail dans un format compatible avec Identity and Access Management (IAM). Chaque cluster est un fournisseur d'identité dans un pool d'identités de charge de travail.

Uniformité de l'identité dans les parcs

Les pools d'identités de charge de travail sont des entités qui fournissent des identités aux charges de travail dans un format qu'IAM peut utiliser lors de l'authentification et de l'autorisation des requêtes. Avec Workload Identity Federation for GKE, chaque projet dispose par défaut d'un pool d'identités de charge de travail fixe et géré par Google, qui est unique à ce projet.

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 pour le projet hôte du parc est le pool d'identités de charge de travail par défaut pour tous les clusters que vous enregistrez dans le parc, que les clusters se trouvent dans d'autres projets ou d'autres clouds. Vous pouvez éventuellement configurer un pool d'identités de charge de travail autogéré pour que des clusters spécifiques l'utilisent à la place du pool par défaut.

Dans la fédération d'identité de charge de travail de parc et dans Workload Identity Federation for GKE, vous utilisez des stratégies d'autorisation IAM pour accorder des rôles sur des Google Cloud ressources spécifiques à des entités de vos clusters, telles que des comptes de service Kubernetes ou des pods. Dans vos stratégies d'autorisation, vous faites référence à ces entités à l'aide d'un identifiant de compte principal, qui est une syntaxe de nommage que IAM peut lire. L'identifiant de compte principal inclut le nom du pool d'identités de charge de travail utilisé par le cluster et d'autres informations qui sélectionnent les entités spécifiques du cluster. Par exemple, l'identifiant de compte principal suivant sélectionne un compte de service Kubernetes dans un espace de noms :

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Dans cet exemple, les champs suivants contiennent des informations sur le compte principal :

  • PROJECT_NUMBER: numéro de projet du projet hôte du parc.
  • WORKLOAD_IDENTITY_POOL_NAME: nom du pool d'identités de charge de travail.
  • NAMESPACE : nom de l'espace de noms.
  • SERVICEACCOUNT: nom du compte de service Kubernetes.

Les requêtes adressées aux Google Cloud API sont authentifiées à l'aide de jetons d'accès OAuth 2.0 de courte durée générés par les clusters. Ces jetons d'accès incluent l'identifiant de compte principal de l'entité qui a créé la requête. IAM utilise l'identifiant de compte principal pour s'assurer qu'une stratégie d'autorisation autorise l'entité à effectuer l'opération demandée.

Implications de l'uniformité de l'identité pour les parcs multilocataires

L'identifiant de compte principal entraîne une uniformité de l'identité, ce qui signifie que toute entité de l'environnement qui correspond à un identifiant de compte principal spécifique est considérée par IAM comme étant la même chose. Avec Workload Identity Federation for GKE à projet unique, l'uniformité de l'identité 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 à toutes les entités qui partagent un identifiant de compte principal dans l'ensemble du parc, quel que soit le projet de cluster.

Par exemple, avec l'identifiant de compte principal de la section précédente, les requêtes provenant de pods qui utilisent le même compte de service, le même espace de noms et le même pool d'identités de charge de travail obtiennent le même identifiant de compte principal, quel que soit le cluster ou le projet.

Si votre parc n'exécute que des clusters dans le projet hôte du parc, les implications de l'uniformité de l'identité sont les mêmes que pour Workload Identity Federation for GKE. Toutefois, si votre parc comporte des clusters qui s'exécutent dans d'autres projets, l'uniformité de l'identité s'étend à tous les clusters enregistrés dans le parc.

Exemples de complexités liées à l'uniformité de l'identité dans les parcs

Les exemples de scénarios suivants décrivent les complexités potentielles liées à l'uniformité de l'identité qui peuvent survenir lorsque vous implémentez la fédération d'identité de charge de travail de parc. Chaque scénario vous propose des mesures d'atténuation possibles qui peuvent vous aider à gérer ces complexités.

Parc à projet unique avec tous les clusters enregistrés et le même pool d'identités de charge de travail

Examinez la configuration de parc suivante :

  • Tous les clusters membres du parc se trouvent dans le projet hôte du parc.
  • Tous les clusters du projet sont membres du parc.
  • Tous les clusters utilisent le même pool d'identités de charge de travail.

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.

Schéma illustrant un projet avec tous les clusters dans un même parc

Comme décrit dans la section Implications de l'uniformité de l'identité pour les parcs, l'utilisation de la fédération d'identité de charge de travail de parc dans ce scénario est identique à celle de Workload Identity Federation for GKE, et aucun risque supplémentaire n'est présent.

Parc à projet unique avec seulement certains clusters enregistrés et le même pool d'identités de charge de travail

Examinez la configuration de parc suivante :

  • Le parc contient deux clusters, qui s'exécutent tous deux dans le projet hôte du parc.
  • Le projet hôte du parc contient un troisième cluster qui n'est pas membre du parc.
  • La fédération d'identité de charge de travail pour GKE est également activée sur le cluster qui n'est pas membre du parc.
  • Tous les clusters du projet utilisent le même pool d'identités de charge de travail.

Schéma illustrant un projet avec seulement certains clusters enregistrés dans un même parc

Avec cette configuration, tous les rôles que vous accordez à une entité d'un cluster du projet s'appliquent aux autres entités du projet qui correspondent à l'identifiant principal. Cela peut entraîner l'attribution involontaire d'autorisations à des entités qui ne font pas partie du parc. Par exemple, l'attribution d'un rôle à un identifiant de compte principal qui sélectionne un compte de service spécifique dans un espace de noms a les implications suivantes :

  • Les charges de travail qui s'exécutent dans l'espace de noms spécifié et qui utilisent le compte de service spécifié dans les clusters membres du parc partagent l'accès.
  • Les charges de travail qui s'exécutent dans le troisième cluster non membre et qui utilisent le même espace de noms et le même nom de compte de service obtiennent également le même accès.

Les suggestions suivantes peuvent vous aider à résoudre cette complexité :

  • Configurez les clusters membres du parc pour qu'ils utilisent un pool d'identités de charge de travail autogéré. Ainsi, les entités des clusters membres du parc auront des identifiants de compte principal différents de ceux du cluster non membre. Pour en savoir plus, consultez la page S'authentifier auprès des API à partir de charges de travail de parc à confiance mixte. Google Cloud

  • Créez un projet hôte de parc dédié et utilisez des règles d'administration pour empêcher l'exécution de clusters dans ce projet. Cela permet de séparer le domaine de confiance du pool d'identités de charge de travail à l'échelle du parc des domaines de confiance au niveau du projet GKE. Seuls les clusters enregistrés partagent le pool d'identités de charge de travail à l'échelle du parc.

    Ces suggestions fonctionnent pour les clusters sur Google Cloud et les clusters associés.

Parc multiprojet avec seulement certains clusters enregistrés et le même pool d'identités de charge de travail

Examinez la configuration de parc suivante :

  • Le parc contient des clusters membres qui s'exécutent dans deux Google Cloud projets : project-1 et project-2.
  • project-1 est le projet hôte du parc. Tous les clusters de project-1 sont membres du parc.
  • project-2 contient un cluster membre du parc et un cluster non enregistré.
  • Tous les clusters de project-1 utilisent le pool d'identités de charge de travail géré par Google du projet, qui est également le pool d'identités de charge de travail par défaut à l'échelle du parc.
  • Le cluster membre du parc dans project-2 utilise le pool d'identités de charge de travail à l'échelle du parc.

Schéma illustrant un parc avec des clusters de deux projets

Dans ce scénario, toutes les autorisations que vous accordez aux entités du projet hôte du parc s'appliquent également aux entités du cluster membre de project-2, car elles partagent toutes le même pool d'identités de charge de travail.

Pour tenter de résoudre cette complexité, créez un projet dédié Google Cloud à utiliser comme projet hôte du parc. Les clusters membres du parc dans project-1 et dans project-2 partagent ensuite par défaut le pool d'identités de charge de travail du projet dédié. Vous pouvez ensuite accorder un accès limité au projet aux clusters de project-1 en utilisant le pool d'identités de charge de travail pour project-1 dans l'identifiant principal.

Empêcher la création d'identités similaires

L'uniformité de l'identité dans les parcs nécessite une implémentation minutieuse du contrôle des accès pour empêcher la création intentionnelle ou involontaire d'identités similaires. Prenons l'exemple d'un scénario dans lequel vous accordez l'accès à tous les pods qui utilisent un compte de service spécifique dans un espace de noms. Si quelqu'un crée cet espace de noms et ce compte de service dans un autre cluster membre du parc, les pods de ce cluster obtiennent le même accès.

Pour réduire les risques de ce problème, utilisez un mécanisme d'autorisation afin d'autoriser uniquement un ensemble d'utilisateurs de confiance à créer, mettre à jour ou supprimer des espaces de noms et des comptes de service Kubernetes.

  • Pour IAM, les autorisations suivantes fournissent cet accès :

    • container.namespaces.*
    • container.serviceAccounts.*

  • Pour le contrôle des accès basé sur les rôles (RBAC) Kubernetes, les ClusterRoles d'exemple suivants configurent un accès spécial pour interagir avec ces ressources Kubernetes :

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-admin
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["create","delete","update","patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: serviceaccount-admin
rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["create","delete","update","patch","impersonate"]

Étape suivante