Réduire les risques d'identité identique dans les parcs multi-locataires

Cette page présente les bonnes pratiques à suivre 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 API Google Cloud dans différents 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 de sécurité qui souhaitent réduire les risques associés à l'identité identique dans les parcs.

Avant de lire cette page, assurez-vous de connaître les concepts de la section À propos de Workload Identity Federation pour parc.

Terminologie

Cette page utilise la terminologie suivante :

  • Fédération d'identité de charge de travail pour 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 du parc: fonctionnalité qui étend la fédération d'identité de charge de travail pour GKE aux charges de travail de l'ensemble du parc, y compris en dehors de Google Cloudet sur plusieurs projets.
  • 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 que IAM peut utiliser lors de l'authentification et de l'autorisation des requêtes. Avec la fédération d'identité de charge de travail pour GKE, chaque projet dispose par défaut d'un pool d'identités de charge de travail fixe géré par Google, qui lui est propre.

Avec la fédération d'identités 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 dans d'autres clouds. Vous pouvez éventuellement configurer un pool d'identités de charge de travail autogéré à utiliser par des clusters spécifiques au lieu du pool par défaut.

Dans la fédération d'identité de charge de travail pour le parc et la fédération d'identité de charge de travail pour GKE, vous utilisez des stratégies d'autorisation IAM pour accorder des rôles sur des ressources Google Cloudspé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 dénomination que IAM peut lire. L'identifiant 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 principal suivant sélectionne un ServiceAccount 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 l'entité principale:

  • PROJECT_NUMBER: numéro 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 envoyées aux API Google Cloud 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 principal de l'entité qui a créé la requête. IAM utilise l'identifiant du compte principal pour s'assurer qu'une stratégie d'autorisation autorise l'entité à effectuer l'opération demandée.

Conséquences de l'uniformité de l'identité sur les parcs multi-locataires

L'identifiant du principal entraîne une identité identique, ce qui signifie que toute entité de l'environnement correspondant à un identifiant de principal spécifique est considérée par IAM comme étant la même chose. 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 principal dans ce projet. Toutefois, avec la fédération d'identité de charge de travail du parc, cette uniformité de l'identité s'applique à toutes les entités qui partagent un identifiant principal dans l'ensemble du parc, quel que soit le projet de cluster.

Par exemple, avec l'identifiant de principal de la section précédente, les requêtes des 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 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'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 exécutés dans d'autres projets, l'identité est identique pour tous les clusters enregistrés du parc.

Exemples de complexités pour l'uniformité de l'identité de parc

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

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

Prenons 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'identité identique pour les parcs, l'utilisation de la fédération d'identité de charge de travail au niveau du parc dans ce scénario est identique à celle de la fédération d'identité de charge de travail pour GKE, et aucun risque supplémentaire n'est présent.

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

Prenons 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 de 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é dans un cluster du projet s'appliquent aux autres entités du projet qui correspondent à l'identifiant principal. Cela peut entraîner l'octroi involontaire d'autorisations à des entités qui ne font pas partie de la flotte. Par exemple, attribuer un rôle à un identifiant principal qui sélectionne un compte de service spécifique dans un espace de noms a les implications suivantes:

  • Les charges de travail exécutées 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 exécutées dans le troisième cluster non membre qui utilisent le même espace de noms et le même nom de compte de service bénéficient également du 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é (version Preview). Cela garantit que les entités des clusters membres du parc ont des identifiants principaux différents de ceux du cluster non membre. Pour en savoir plus, consultez la section S'authentifier auprès des API Google Cloud à partir de charges de travail de parc de confiance mixte.

  • Créez un projet hôte de parc dédié et utilisez les règles d'administration pour empêcher le projet hôte de parc dédié d'exécuter des clusters. 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 certains clusters enregistrés et le même pool d'identités de charge de travail

Prenons 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 correspond au projet hôte du parc. Tous les clusters de project-1 sont membres du parc.
  • project-2 contient un cluster membre de 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 pour l'ensemble 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 à partir de project-2, car elles partagent toutes le même pool d'identités de charge de travail.

Pour essayer de résoudre cette complexité, créez un projet Google Cloud dédié à utiliser comme projet hôte du parc. Les clusters membres du parc dans project-1 et project-2 partagent ensuite le pool d'identités de charge de travail du projet dédié par défaut. Vous pouvez ensuite accorder un accès de portée projet aux clusters dans project-1 à l'aide du 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 que vous implémentiez soigneusement le contrôle des accès pour éviter la création intentionnelle ou non intentionnelle d'identités similaires. Par exemple, imaginons que 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 de la flotte, 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 pour n'autoriser qu'un ensemble d'utilisateurs de confiance à créer, modifier 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, l'exemple de ClusterRoles suivant configure 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"]

Étapes suivantes