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

Cette page fournit les bonnes pratiques pour configurer et utiliser la fédération d'identité de charge de travail de parc. Il s'agit d'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 plates-formes, ainsi qu'aux ingénieurs en sécurité qui souhaitent minimiser 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 dans 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 qu'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é de charge de travail du 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 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 ou des pods Kubernetes. 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 permettant de sélectionner 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 le principal :

  • 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 éphémères 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 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 mutualisés

L'identifiant du compte principal entraîne une identité identique, 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 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 principal dans ce projet. Toutefois, avec la fédération d'identité de charge de travail du parc, cette uniformité d'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 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'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, l'identité identique s'étend à tous les clusters enregistrés dans le parc.

Exemples de complexités liées à l'uniformité de l'identité dans un parc

Les exemples de scénarios suivants décrivent les complexités potentielles liées à l'identité qui peuvent survenir lorsque vous implémentez la fédération d'identité de charge de travail pour un parc. Chaque scénario vous propose des solutions 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

Prenons l'exemple de 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 flottes, l'utilisation de la fédération d'identité de charge de travail de 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 à projet unique avec seulement certains clusters enregistrés et le même pool d'identités de charge de travail

Prenons l'exemple de la configuration de parc suivante :

  • Le parc contient deux clusters, qui s'exécutent tous les 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, accorder 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 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 bénéficient également du même accès.

Les suggestions suivantes peuvent vous aider à résoudre ce problème de complexité :

  • Configurez les clusters membres du parc pour qu'ils utilisent un pool d'identités de charge de travail autogéré (aperçu). 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 S'authentifier auprès des API Google Cloud à partir de charges de travail de parc à confiance mixte.

  • Créez un projet hôte de parc dédié et utilisez des 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 l'exemple de la configuration de parc suivante :

  • Le parc contient des clusters membres qui s'exécutent dans deux projets Google Cloud : project-1 et project-2.
  • project-1 est le projet hôte du parc. Tous les clusters de project-1 sont des 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 Google Cloud projet dédié à utiliser comme projet hôte du parc. Les clusters membres du parc dans project-1 et dans 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 au niveau du 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 éviter la création intentionnelle ou non intentionnelle d'identités similaires. Par exemple, imaginons que vous accordiez 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 rencontrer ce problème, utilisez un mécanisme d'autorisation afin de 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 permettent cet accès :

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

  • Pour le contrôle des accès basé sur les rôles (RBAC) de Kubernetes, les ClusterRoles de l'exemple suivant 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"]

Étapes suivantes