GKE Workload Identity devient Workload Identity Federation — qu'est-ce qui change ?

WIF est une fonctionnalité conçue pour faire le pont entre les systèmes d'identité externes et Google Cloud IAM. Elle permet aux organisations d'étendre leur infrastructure d'identité existante — Active Directory, AWS, Okta, etc. — aux ressources Google Cloud de façon transparente.

En établissant des relations de confiance entre les fournisseurs d'identité externes (IdP) et Google Cloud IAM, WIF permet aux utilisateurs et applications authentifiés via des systèmes autres que GCP d'accéder aux ressources GCP avec leurs identités existantes.

Pour établir cette relation de confiance, vous créez d'abord un Workload Identity Pool destiné à gérer les identités externes, puis vous y ajoutez des Workload Identity Providers, chacun décrivant la relation entre votre IdP et GCP.

Une fois la relation établie, un token d'identification émis par votre IdP peut être vérifié par le Security Token Service de Google et échangé contre un token fédéré servant à s'authentifier auprès de GCP.

Avec Workload Identity Federation for GKE (anciennement Workload Identity tout court), Google gère pour vous le pool et le provider.

Chaque projet GCP dispose d'un pool fixe unique (PROJECT_ID.svc.id.goog) ; une fois la fonctionnalité activée sur un cluster GKE, celui-ci est enregistré comme fournisseur d'identité au sein de ce pool.

Le serveur de métadonnées GKE est alors déployé automatiquement sur tous les nœuds du cluster sous forme de DaemonSet. Il sert notamment à intercepter les requêtes émises par vos workloads et à renvoyer le bon token pour le service account que votre workload doit impersonner.

C'est précisément l'objectif de cette fonctionnalité : permettre à vos workloads GKE d'accéder aux ressources GCP sans transmettre de credentials explicites, ni même recourir au Service Account IAM du Node sous-jacent.

La première étape consiste à activer WIF sur votre cluster GKE et vos node pools si ce n'est pas déjà fait — point bien documenté et hors sujet pour cet article.

Ensuite, vous devez créer un Kubernetes Service Account (KSA) que votre workload utilisera (en le configurant dans la spec du Pod).

Avec Workload Identity (WI), deux options s'offrent ensuite à vous pour accorder des permissions GCP IAM à vos workloads :

Via l'impersonation d'un Google IAM Service Account

Jusqu'à récemment, c'était la seule méthode standard pour configurer WI ; elle est désormais documentée comme la méthode alternative.

En résumé, il faut créer un Google Service Account (GSA) et lui accorder les permissions IAM nécessaires à votre workload. Un binding doit ensuite être créé entre le GSA et le KSA en attribuant au KSA le rôle roles/iam.workloadIdentityUser sur le GSA, puis en annotant le KSA en conséquence.

Via les identifiants de principal IAM

Voilà la grande nouveauté évoquée en introduction. Les ressources Kubernetes peuvent désormais être référencées directement dans les politiques IAM en tant que principals.

Vous pouvez référencer votre KSA par nom (pour bénéficier de l'identity sameness) ou par UID (disponible dans la spec du KSA après sa création).

Vous pouvez même cibler tous les pods d'un cluster lorsqu'une même permission IAM est requise par l'ensemble de vos workloads.

Source : https://twitter.com/_techcet_/status/1773865010651173293

Comme le montre le tableau ci-dessus, la possibilité de désigner les ressources Kubernetes comme principals IAM simplifie nettement la configuration.

Plutôt que de gérer un GSA supplémentaire et de penser à autoriser votre KSA à l'impersonner (étape souvent oubliée), vous pouvez accorder les rôles IAM nécessaires directement au KSA. Plus besoin non plus d'annoter votre KSA avec le nom du GSA — encore une étape facilement mal configurée ou oubliée.

Pouvoir référencer un KSA par UID plutôt que par nom est un excellent ajout, qui réduit le risque d'accorder par inadvertance un accès à des workloads non souhaités via l'identity sameness. Cela dit, l'identity sameness peut s'avérer utile si elle est utilisée à bon escient, et elle reste possible avec les deux versions de la configuration.

Par ailleurs, pouvoir désigner tous les pods d'un cluster comme un ensemble de principals IAM apporte une réelle flexibilité. Je suis convaincu que dans les mois à venir, le support sera étendu à d'autres types de ressources Kubernetes en tant que principals IAM (les namespaces seraient un excellent ajout).

Une limitation actuelle des principals IAM : une poignée de services ne sont pas encore pris en charge ou restent en preview. Si vous utilisez actuellement WI pour accéder à l'un d'entre eux, mieux vaut différer la mise à niveau de votre configuration.

Bonne nouvelle : rien ne vous y oblige. La méthode par impersonation de GSA reste prise en charge et ne devrait pas disparaître de sitôt.

Cela dit, les principals IAM simplifient la configuration et apportent plusieurs avantages décrits dans la section précédente. Je recommande donc d'adopter cette approche dès que possible.

Quelle est la manière la plus fluide de basculer vos workloads de leur configuration actuelle vers les principals IAM ?

Si vous utilisez actuellement Workload Identity pour accéder aux ressources GCP, vous disposez d'un GSA doté des permissions IAM nécessaires et d'un KSA possédant le rôle IAM Workload Identity User sur ce GSA.

Enfin, votre KSA est annoté pour pointer vers le GSA, par exemple :

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
  ...

Voyons s'il est possible de mettre à jour la configuration WI sans interruption de service.

Commençons par lancer un pod qui utilise ce KSA pour quelques tests :

$ echo 'apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
spec:
  serviceAccountName: <KSA_NAME>
  containers:
  - image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    name: workload-identity-test' | kubectl apply -f -

Une fois le pod prêt et en cours d'exécution, on peut s'y connecter via exec :

$ kubectl exec -ti token-test -- bash

Depuis l'intérieur du pod, on peut interroger le serveur de métadonnées pour vérifier quelle identité notre pod utilise :

root@token-test:/# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
{"aliases":["default"],"email":"<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com","scopes":["https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/userinfo.email"]}

Le champ email de la réponse confirme que notre identité correspond bien au GSA que notre KSA est configuré pour utiliser (via l'annotation sur le KSA).

Que se passe-t-il si nous supprimons cette annotation du KSA ?

# à exécuter en dehors du pod
$ kubectl annotate serviceaccount <KSA_NAME> iam.gke.io/gcp-service-account-

Réessayons la requête :

root@token-test:/# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
{"aliases":["default"],"email":"<PROJECT_ID>.svc.id.goog","scopes":["https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/userinfo.email"]}

Comme vous pouvez le constater, notre identité bascule immédiatement vers le Workload Identity Pool du projet. Autrement dit, le passage de l'impersonation GSA au binding par principal IAM devrait s'opérer sans même redémarrer les pods (à noter que certains clients pourront nécessiter un redémarrage pour adopter la nouvelle identité).

En partant du principe que votre KSA est toujours annoté avec le GSA et que le workload fonctionne :

1. Créez la politique IAM pour accorder les rôles IAM nécessaires directement au KSA (les mêmes que ceux accordés à votre GSA)
2. Supprimez l'annotation WI du KSA. À ce stade, le pod devrait immédiatement utiliser les permissions accordées au principal KSA (en cas d'erreurs, un redémarrage du pod devrait suffire)
3. Une fois le bon fonctionnement confirmé, vous pouvez supprimer le GSA devenu inutile et veiller à ce que votre IaC et vos manifests soient à jour