Workload Identity pour GKE : analyse des erreurs courantes

Découvrez GKE Workload Identity Analyzer, l'outil DoiT qui analyse vos workloads sur GKE et garantit une configuration correcte de Workload Identity.

workload-identity-for-gke (1)

GKE Workload Identity Analyzer : la garantie d'une configuration Workload Identity correcte

Si vous utilisez Google Kubernetes Engine (GKE) et que vos workloads communiquent avec d'autres services Google Cloud, vous utilisez probablement Workload Identity. Et si ce n'est pas le cas, vous devriez. Google recommande Workload Identity pour les workloads exécutés sur Google Kubernetes Engine (GKE) afin d'accéder aux services Google Cloud de manière sécurisée et facilement gérable.

Les alternatives à Workload Identity

Les autres options (un peu datées) pour l'authentification entre GKE et Google Cloud sont les suivantes :

utiliser le compte de service Compute Engine par défaut, dont le périmètre est généralement trop large et qui ne peut pas être personnalisé pour chaque workload
fournir des secrets de compte de service à vos workloads, ce qui représente un risque de sécurité puisque ces clés ont une longue durée de vie et exigent de la vigilance, ainsi qu'une rotation régulière conforme aux bonnes pratiques

Le fonctionnement de Workload Identity

Workload Identity échappe à tous ces écueils : il se configure workload par workload et ne demande ni gestion ni injection de secrets dans votre workload.

Concrètement, il établit une relation entre un Kubernetes Service Account (KSA) et un Google Service Account (GSA). Le KSA sert à identifier votre workload exécuté dans GKE comme étant l'utilisateur du GSA, et le GSA est lui-même configuré avec les accès nécessaires aux ressources Google Cloud. Cet accès peut être aussi large ou aussi restreint que le workload l'exige : un workload qui doit accéder à tous les topics PubSub d'un projet, par exemple, comparé à un autre qui n'a besoin que d'un seul (ou de quelques-uns).

Les avantages de Workload Identity sont évidents, mais sa mise en place demande quelques étapes de configuration supplémentaires qui peuvent dérouter au premier abord.

Une mauvaise configuration peut se glisser dans n'importe quel maillon de la chaîne d'authentification entre un Pod exécuté dans GKE et un service hébergé dans un projet GCP. De quoi rendre le diagnostic particulièrement fastidieux.

Le rôle de GKE Workload Identity Analyzer

C'est précisément la raison d'être de GKE Workload Identity Analyzer, développé par DoiT. Cet outil en ligne de commande prend un nom de pod en argument et procède à une série de vérifications de configuration pour s'assurer que WI est correctement paramétré pour votre workload. Il contrôle les points suivants :

Workload Identity est activé sur le cluster GKE
Le Pod a bien .spec.serviceAccountName configuré
Le KSA (configuré à l'étape précédente) existe
Le KSA est correctement annoté avec un GSA
Le GSA (configuré à l'étape précédente) existe dans le projet
Le KSA dispose du rôle roles/iam.workloadIdentityUser sur le GSA

Pour finir, l'outil vérifie et liste les rôles IAM attribués au GSA dans le projet (notez qu'il ne vérifie pas les rôles IAM accordés sur un périmètre plus restreint, comme une ressource GCP spécifique : PubSub Topic, instance CloudSQL, etc.).

Il s'exécute en moins de 10 secondes et fait gagner un temps précieux par rapport à une inspection manuelle des ressources dans la console ou via le terminal.

Écrit en Python, l'outil est publié sur PyPI. Il s'installe en un clin d'œil avec PIP :

$ pip install wi-analyzer

Lancer GKE Workload Identity Analyzer

Voici les prérequis à son exécution :

gcloudcli installé et configuré
Application Default Credentials générées via gcloud
kubectl installé et configuré avec accès au cluster

Notez que l'outil récupère certaines informations depuis votre contexte kubeconfig actuel. Il s'attend également au nom généré par défaut pour un cluster GKE lors de la récupération des identifiants (au format : gke_<GCP_PROJECT_ID>__<CLUSTER_NAME>).

Vous pouvez aussi passer des arguments pour spécifier l'ID du projet GCP, l'emplacement et le nom du cluster.

Une fois tout en place, lancez l'outil depuis le terminal :

$ wi-analyzer --help
usage: wi-analyzer [-h] [-n NAMESPACE] [-d] pod

GKE Workload Identity Analyzer

positional arguments:
  pod                   Kubernetes Pod name to check

options:
  -h, --help            show this help message and exit
  -n NAMESPACE, --namespace NAMESPACE
                        Kubernetes Namespace to run in
  -p PROJECT, --project PROJECT
                        GCP Project holding the cluster
  -l LOCATION, --location LOCATION
                        The GCP location of the cluster
  -c CLUSTER, --cluster CLUSTER
                        The name of the cluster

  -d, --debug           Enable debug logging

Imaginons par exemple que je suive la documentation pour configurer mon workload avec WI et que j'oublie une étape anodine. La sortie de l'outil pourrait bien m'aider à y voir clair :

$ wi-analyzer demo-pod
Check results
---------------------------
V=Passed, X=Failed, -=Skipped

[V] GCP project and GKE info determined from current context
[V] Namespace passed as argument,or determined from current context
[V] Workload Identity enabled on GKE Cluster
[V] Pod found in current context
[V] GKE Node found in the cluster
[V] Workload Identity enabled on Node Pool
[V] KSA found in the cluster
[X] KSA Workload Identity annotation set correctly
[-] GSA found in GCP project
[-] GSA is enabled
[-] GSA has Workload Identity users configured
[-] GSA does not have KSA as a Workload Identity user

GKE cluster info
---------------------------
Cluster: "projects/test-eyal/locations/europe-west1-b/clusters/playground"
Workload: "demo/demo-pod" running on Node: "gke-playground-nodepool-1f1ace09-96kr"
KSA name: "demo-ksa"

Google Service Account info
---------------------------
Google Service Account information could not be determined, fix previous issues

Comme le suggère la sortie, l'annotation WI manquait sur le KSA. Une fois corrigée, une nouvelle exécution de l'outil ne devrait plus afficher que des vérifications réussies et un aperçu complet :

$ wi-analyzer demo-pod
Check results
---------------------------
V=Passed, X=Failed, -=Skipped

[V] GCP project and GKE info determined from current context
[V] Namespace passed as argument,or determined from current context
[V] Workload Identity enabled on GKE Cluster
[V] Pod found in current context
[V] GKE Node found in the cluster
[V] Workload Identity enabled on Node Pool
[V] KSA found in the cluster
[V] KSA Workload Identity annotation set correctly
[V] GSA found in GCP project
[V] GSA is enabled
[V] GSA has Workload Identity users configured
[V] GSA does not have KSA as a Workload Identity user

GKE cluster info
---------------------------
Cluster: "projects/test-eyal/locations/europe-west1-b/clusters/playground"
Workload: "demo/demo-pod" running on Node: "gke-playground-nodepool-1f1ace09-96kr"
KSA name: "demo-ksa"

Google Service Account info
---------------------------
Google Service Account: "projects/test-eyal/serviceAccounts/[email protected]"
Has the following Workload Identity Users:
serviceAccount:test-eyal.svc.id.goog[demo/demo-ksa]

GSA: "[email protected]" has the following roles in project "test-eyal":
roles/cloudsql.client
Workload Identity configured properly - check if any IAM roles are missing from the list above

L'outil ne prend pour l'instant en charge que GKE Standard, mais la prise en charge de Fleet Workload Identity (GKE WI pour Anthos) figure sur la feuille de route. Des tests sur les clusters Anthos multicloud sont déjà en cours, mais ils impliqueront des évolutions de fond dans l'outil. Restez à l'affût !

Vous avez repéré un bug ? Vous avez des idées de fonctionnalités ?

N'hésitez pas à nous le faire savoir, ici en commentaire ou en ouvrant un ticket sur le dépôt GitHub.