La fédération d'identité de charge de travail pour GKE est la méthode 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.
La fédération d'identité de charge de travail pour GKE est disponible via la fédération d'identité de charge de travail IAM, qui fournit des identités pour les charges de travail exécutées dans des environnements internes et externes à Google Cloud. Vous pouvez utiliser la fédération d'identité de charge de travail IAM pour vous authentifier de manière sécurisée auprès des API Google Cloud compatibles à partir de charges de travail exécutées, par exemple, sur AWS, Azure, et Kubernetes autogéré. Dans GKE, Google Cloud gère automatiquement le pool d'identités de charge de travail et le fournisseur, et ne nécessite pas de fournisseur d'identité externe.
- Pour en savoir plus sur la fédération d'identité de charge de travail dans d'autres environnements, consultez la page Fédération d'identité de charge de travail.
- Pour activer et utiliser la fédération d'identité de charge de travail pour GKE, consultez la page Accéder aux API Google Cloud à partir de charges de travail GKE.
- Pour assurer la compatibilité avec la fédération d'identité de charge de travail pour les clusters dans des parcs, utilisez l'identité de charge de travail de parc.
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 la fédération d'identité de charge de travail pour GKE ?
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.
La fédération d'identité de charge de travail pour GKE vous permet d'utiliser des stratégies IAM pour accorder aux charges de travail Kubernetes de votre cluster GKE l'accès à des API Google Cloud spécifiques sans avoir à recourir à une configuration manuelle ou à des méthodes moins sécurisées telles que les fichiers de clé de compte de service. La fédération d'identité de charge de travail pour GKE vous permet d'attribuer des identités et des autorisations distinctes et précises pour chaque application de votre cluster.
La fédération d'identité de charge de travail pour GKE évite d'avoir à 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 la fédération d'identité de charge de travail pour GKE.
Fonctionnement de la fédération d'identité de charge de travail pour GKE
Lorsque vous activez la fédération d'identité de charge de travail pour GKE sur un cluster, GKE effectue les opérations suivantes :
Crée un pool d'identités de charge de travail fixe pour le projet Google Cloud du cluster au format suivant :
PROJECT_ID.svc.id.googLe pool d'identités de charge de travail fournit un format de nom qui permet à IAM de comprendre et d'approuver les identifiants Kubernetes.
Enregistre le cluster GKE en tant que fournisseur d'identité dans le pool d'identités de charge de travail.
Déploie le serveur de métadonnées GKE, qui intercepte les demandes d'identifiants provenant de charges de travail sur chaque nœud.
Créer des stratégies d'autorisation IAM sur des ressources Google Cloud
Pour fournir un accès avec la fédération d'identité de charge de travail pour GKE, vous devez créer une stratégie d'autorisation IAM qui accorde l'accès à une ressource Google Cloud spécifique à un compte principal correspondant à l'identité de votre application. Vous pouvez par exemple accorder des autorisations de lecture sur un bucket Cloud Storage à tous les pods utilisant le compte de service Kubernetes database-reader.
Pour obtenir la liste des ressources compatibles avec les stratégies d'autorisation, consultez la section Types de ressources compatibles avec les stratégies d'autorisation.
Vous pouvez également limiter le niveau d'accès en définissant des conditions dans vos stratégies d'autorisation. Par exemple, si vous souhaitez uniquement accorder un accès en lecture sur un bucket aux pods qui utilisent le compte de service database-reader dans le cluster mysql, vous pouvez définir cette condition dans votre stratégie d'autorisation. Pour en savoir plus sur l'utilisation des conditions dans les stratégies d'autorisation, consultez la section Gérer les liaisons de rôles conditionnelles.
Référencer les ressources Kubernetes dans les stratégies IAM
Dans votre stratégie IAM, vous faites référence à une ressource Kubernetes en utilisant un identifiant de compte principal IAM pour la sélectionner. Cet identifiant utilise la syntaxe suivante :
PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR
Dans cet exemple, examinez les champs suivants :
PREFIX: doit êtreprincipalouprincipalSeten fonction de la ressource que vous sélectionnez.principalcorrespond à une ressource spécifique, comme un compte de service unique.principalSetcorrespond à plusieurs ressources appartenant à la ressource spécifiée, comme tous les pods d'un cluster spécifique.SELECTOR: chaîne qui sélectionne un type de compte principal. Par exemple,kubernetes.serviceaccount.uid/SERVICEACCOUNT_UIDsélectionne un compte de service en fonction de son UID.
Le tableau suivant présente les types de comptes principaux compatibles avec GKE :
| Type d'identifiant de compte principal | Syntaxe |
|---|---|
| Tous les pods qui utilisent un compte de service Kubernetes spécifique | Sélectionner le compte de service par nom :
principal://iam.googleapis.com/projects/Remplacez les éléments suivants :
Sélectionner le compte de service par UID : principal://iam.googleapis.com/projects/
Remplacez les éléments suivants :
|
| Tous les pods d'un cluster spécifique | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME Remplacez les éléments suivants :
|
Flux des identifiants
Lorsqu'une charge de travail envoie une requête d'accès à une API Google Cloud, par exemple lors de l'utilisation d'une bibliothèque cliente Google Cloud, les étapes d'authentification suivantes se produisent :
- Les identifiants par défaut de l'application demandent un jeton d'accès Google Cloud au serveur de métadonnées Compute Engine qui s'exécute sur la VM.
- Le serveur de métadonnées GKE intercepte la requête de jeton et demande au serveur d'API Kubernetes un jeton Kubernetes ServiceAccount qui identifie la charge de travail à l'origine de la requête. Cet identifiant est un jeton Web JSON (JWT) signé par le serveur d'API.
- Le serveur de métadonnées GKE utilise Security Token Service pour échanger le jeton JWT contre un jeton d'accès Google Cloud fédéré de courte durée qui fait référence à l'identité de la charge de travail Kubernetes.
- Le serveur de métadonnées GKE fournit le jeton d'accès fédéré à la charge de travail.
La charge de travail peut ensuite accéder à toutes les API Google Cloud auxquelles l'identifiant principal IAM de la charge de travail peut accéder.
Uniformité de l'identité
Si les métadonnées de votre identifiant principal sont les mêmes pour les charges de travail de plusieurs clusters qui partagent un pool d'identités de charge de travail car elles appartiennent au même projet Google Cloud, IAM identifie ces charges de travail comme étant les mêmes. Par exemple, si vous avez le même espace de noms dans deux clusters et que vous accordez l'accès à cet espace de noms dans IAM, les charges de travail dans cet espace de noms dans les deux clusters obtiennent cet accès. Vous pouvez limiter cet accès à des clusters spécifiques à l'aide de stratégies IAM conditionnelles.
Par exemple, considérons le diagramme suivant. Les clusters A, B et C appartiennent au même pool d'identités de charge de travail. Google Cloud identifie les applications qui utilisent le compte de service back-ksa dans l'espace de noms backend du cluster A et du cluster B comme étant la même identité. 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 back-ksa, 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 identifiant principal commun.
Comprendre le serveur de métadonnées GKE
Chaque nœud d'un cluster GKE sur lequel la fédération d'identité de charge de travail pour GKE est activée 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 liées à la fédération d'identité de charge de travail pour GKE
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.
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 la fédération d'identité de charge de travail pour GKE ayant lieu 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.
La fédération d'identité de charge de travail pour GKE nécessite une configuration manuelle pour que Knative serving continue à générer des métriques de requêtes.
La fédération d'identité de charge de travail pour GKE définit une limite de 200 connexions au serveur de métadonnées GKE pour chaque nœud, 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.
La fédération d'identité de charge de travail pour GKE 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 à la fédération d'identité de charge de travail pour GKE
Afin d'accéder aux API Google Cloud à partir de GKE, vous pouvez utiliser l'une des alternatives suivantes à la fédération d'identité de charge de travail pour GKE. Nous vous recommandons d'utiliser la fédération d'identité de charge de travail pour GKE, car ces alternatives nécessitent certains compromis de sécurité.
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 pour le 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.
Exportez les clés de compte de service et stockez-les en tant que secrets Kubernetes à installer sur vos pods en tant que volumes.
Étapes suivantes
- Découvrez comment activer et configurer la fédération d'identité de charge de travail pour GKE.
- Obtenez plus d'informations sur le serveur de métadonnées Compute Engine.