Workload Identity est la solution recommandée pour que vos charges de travail s'exécutant sur Google Kubernetes Engine (GKE) puissent accéder aux services Google Cloud de manière sécurisée et gérable.
Pour en savoir plus sur l'activation et l'utilisation de Workload Identity dans GKE, consultez la page Utiliser Workload Identity.
Vous pouvez utiliser l'identité de charge de travail de parc pour assurer la compatibilité avec la fédération d'identité de charge de travail pour les clusters enregistrés dans des parcs, y compris les clusters Anthos.
Terminologie
Ce document distingue les comptes de service Kubernetes et les comptes de service Identity and Access Management (IAM).
- Comptes de service Kubernetes
- Ressources Kubernetes fournissant une identité pour les processus exécutés dans vos pods GKE.
- Comptes de service IAM
- Ressources Google Cloud permettant aux applications d'effectuer des appels autorisés vers les API Google Cloud.
Qu'est-ce que Workload Identity ?
Les applications exécutées sur GKE peuvent avoir besoin d'accéder aux API Google Cloud telles que Compute Engine, BigQuery Storage ou Machine Learning.
Workload Identity permet à un compte de service Kubernetes de votre cluster GKE d'agir en tant que compte de service IAM. Les pods qui utilisent le compte de service Kubernetes configuré s'authentifient automatiquement en tant que compte de service IAM lorsqu'ils accèdent aux API Google Cloud. L'utilisation de Workload Identity vous permet d'attribuer des identités et une autorisation distinctes et précises pour chaque application de votre cluster.
Avec Workload Identity, vous n'avez pas besoin d'utiliser la dissimulation de métadonnées. Les métadonnées sensibles protégées par la dissimulation de métadonnées sont également protégées par Workload Identity.
Fonctionnement de Workload Identity
Lorsque vous activez Workload Identity sur un cluster, GKE crée automatiquement un pool d'identités de charge de travail fixe pour le projet Google Cloud du cluster au format suivant :
PROJECT_ID.svc.id.goog
Le pool d'identités de charge de travail fournit un format de nom qui permet à IAM de comprendre et d'approuver les identifiants du compte de service Kubernetes. L'activation de Workload Identity n'accorde à vos charges de travail aucune autorisation IAM par défaut.
Lorsque vous configurez un compte de service Kubernetes dans un espace de noms afin qu'il utilise Workload Identity, IAM authentifie les identifiants avec le nom de membre suivant :
serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SERVICE_ACCOUNT]
Dans ce nom de membre :
PROJECT_ID: ID de votre projet Google Cloud.KUBERNETES_NAMESPACE: espace de noms du compte de service Kubernetes.KUBERNETES_SERVICE_ACCOUNT: nom du compte de service Kubernetes qui envoie la requête.
Le processus de configuration de Workload Identity comprend l'utilisation d'une liaison de stratégie IAM pour lier le nom du membre du compte de service Kubernetes à un compte de service IAM disposant des autorisations requises pour vos charges de travail. Tous les appels d'API Google Cloud provenant de charges de travail utilisant ce compte de service Kubernetes sont authentifiés en tant que compte de service IAM lié.
Uniformité de l'identité
Le nom de membre utilisé par IAM pour vérifier un compte de service Kubernetes avec Workload Identity utilise les variables suivantes :
- Nom du compte de service Kubernetes.
- Espace de noms du compte de service Kubernetes.
- ID de projet Google Cloud.
Si votre projet comporte plusieurs clusters portant le même nom et le même espace de noms pour un compte de service Kubernetes, tous les comptes sont associés au même nom de membre. Cette identité commune vous permet d'accorder l'accès aux ressources Google Cloud au pool d'identités de charge de travail plutôt qu'à des clusters individuels.
Par exemple, considérons le diagramme suivant. Les clusters A, B et C appartiennent au même projet Google Cloud et, par conséquent, au même pool d'identités de charge de travail.
Les applications de l'espace de noms backend du cluster A et du cluster B peuvent s'authentifier en tant que compte de service IAM back lors de l'accès aux ressources Google Cloud. IAM ne fait pas la distinction entre les clusters qui effectuent les appels.
Cette uniformisation de l'identité signifie également que vous devez pouvoir approuver chaque cluster dans un pool d'identités de charge de travail spécifique. Par exemple, si le cluster C de l'exemple précédent appartient à une équipe non approuvée, il est possible de créer un espace de noms backend et d'accéder aux API Google Cloud à l'aide du compte de service IAM back, comme pour le cluster A et le cluster B.
Pour éviter tout accès non approuvé, placez vos clusters dans des projets distincts afin de vous assurer qu'ils obtiennent des pools d'identités de charge de travail différents, ou assurez-vous que les noms d'espace de noms sont distincts les uns des autres pour éviter un nom de membre commun.
Comprendre le serveur de métadonnées GKE
Chaque nœud d'un cluster GKE sur lequel Workload Identity est activé stocke ses métadonnées sur le serveur de métadonnées GKE. Le serveur de métadonnées GKE est un sous-ensemble des points de terminaison du serveur de métadonnées Compute Engine requis pour les charges de travail Kubernetes.
Le serveur de métadonnées GKE s'exécute en tant que DaemonSet, avec un pod sur chaque nœud Linux ou un service Windows natif sur chaque nœud Windows du cluster. Le serveur de métadonnées intercepte les requêtes HTTP envoyées à http://metadata.google.internal (169.254.169.254:80). Par exemple, la requête GET
/computeMetadata/v1/instance/service-accounts/default/token récupère un jeton pour le compte de service IAM dont le pod doit emprunter l'identité d'après sa configuration.
Le trafic vers le serveur de métadonnées GKE ne quitte jamais l'instance de VM qui héberge le pod.
Les tableaux suivants décrivent le sous-ensemble de points de terminaison du serveur de métadonnées Compute Engine disponibles avec le serveur de métadonnées GKE. Pour obtenir la liste complète des points de terminaison disponibles sur le serveur de métadonnées Compute Engine, consultez la page Valeurs de métadonnées de VM par défaut.
Métadonnées de l'instance
Les métadonnées d'instance sont stockées dans le répertoire suivant.
http://metadata.google.internal/computeMetadata/v1/instance/
| Entrée | Description |
|---|---|
hostname |
Nom d'hôte de votre nœud. |
id |
ID unique du nœud. |
service-accounts/ |
Répertoire des comptes de service associés au nœud. Pour chaque compte de service, les informations suivantes sont disponibles :
|
zone |
Zone Compute Engine de votre nœud GKE. |
Attributs des instances
Les attributs d'instance sont stockés dans le répertoire suivant.
http://metadata.google.internal/computeMetadata/v1/instance/attributes/
| Entrée | Description |
|---|---|
cluster-location |
Zone ou région Compute Engine de votre cluster. |
cluster-name |
Nom de votre cluster GKE. |
cluster-uid |
UID de votre cluster GKE. |
Métadonnées du projet
Les métadonnées du projet de cluster sont stockées dans le répertoire suivant.
http://metadata.google.internal/computeMetadata/v1/project/
| Entrée | Description |
|---|---|
project-id |
L'ID de votre projet Google Cloud. |
numeric-project-id |
Numéro de votre projet Google Cloud. |
Restrictions propres à Workload Identity
Vous ne pouvez pas modifier le nom du pool d'identités de charge de travail créé par GKE pour votre projet Google Cloud.
Lorsque GKE active le serveur de métadonnées GKE sur un pool de nœuds, les pods ne peuvent plus accéder au serveur de métadonnées Compute Engine. Au lieu de cela, le serveur de métadonnées GKE intercepte les requêtes émises depuis ces pods vers les points de terminaison des métadonnées, à l'exception des pods s'exécutant sur le réseau hôte.
Workload Identity ne peut pas être utilisé par des pods en cours d'exécution sur le réseau hôte. Les requêtes envoyées par ces pods aux points de terminaison des métadonnées sont acheminées vers le serveur de métadonnées Compute Engine.
Le serveur de métadonnées GKE met quelques secondes pour commencer à accepter des requêtes sur un pod créé récemment. Par conséquent, les tentatives d'authentification à l'aide de Workload Identity dans les premières secondes de la vie d'un pod peuvent échouer. Une nouvelle tentative d'appel permet de résoudre le problème. Consultez la section Dépannage pour plus d'informations.
Les agents de journalisation et de surveillance intégrés à GKE continuent à utiliser le compte de service du nœud.
Workload Identity doit être configuré manuellement pour que Cloud Run for Anthos continue à générer des métriques de requêtes.
Workload Identity définit une limite de 200 connexions au serveur de métadonnées GKE pour chaque nœud, ce afin d'éviter les problèmes de mémoire. Vous risquez de subir des expirations de délais si vos nœuds dépassent cette limite.
Workload Identity pour les nœuds Windows Server est disponible dans les versions GKE 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 et ultérieures.
Le serveur de métadonnées GKE utilise une quantité de ressources mémoire proportionnelle au nombre total de comptes de service Kubernetes dans votre cluster. Si votre cluster contient plus de 3 000 comptes de service Kubernetes, le kubelet peut mettre fin aux pods du serveur de métadonnées. Pour découvrir les mesures d'atténuation des erreurs, consultez la section Dépannage.
Alternatives à Workload Identity
Vous pouvez utiliser l'une des alternatives suivantes à Workload Identity pour accéder aux API Google Cloud à partir de GKE.
Exportez les clés de compte de service et stockez-les en tant que secrets Kubernetes. Les clés de compte de service Google n'expirent pas et nécessitent une rotation manuelle. L'exportation de clés de compte de service permet d'élargir le champ d'application d'une brèche de sécurité si celle-ci n'a pas été détectée. En cas de vol d'une clé exportée, un pirate informatique peut l'utiliser pour s'authentifier en tant que compte de service jusqu'à ce que vous constatiez et révoquiez manuellement la clé.
Utilisez le compte de service par défaut Compute Engine de vos nœuds. Vous pouvez exécuter des pools de nœuds en tant que compte de service IAM dans votre projet. Si vous ne spécifiez pas de compte de service lors de la création du pool de nœuds, GKE utilise le compte de service Compute Engine par défaut du projet. Le compte de service Compute Engine est partagé par toutes les charges de travail déployées sur ce nœud. Cela peut entraîner un surprovisionnement des autorisations, ce qui est contraire au principe du moindre privilège et est inapproprié pour les clusters mutualisés.
Étape suivante
- Découvrez comment activer et configurer Workload Identity.
- Obtenez plus d'informations sur le serveur de métadonnées Compute Engine.