
Il est fréquent de vouloir configurer ses services Kubernetes pour qu'ils utilisent un compte de service Google précis (à la manière du projet kube2iam).

Pour y parvenir, configurez un compte de service Kubernetes afin qu'il agisse comme un compte de service Google. Tout Pod exécutant :
ServiceAccountName: <kubernetes_service_account>s'authentifiera alors auprès des services gcloud avec ce compte de service Google.
À noter : il s'agit d'un produit en bêta, susceptible d'évoluer.
Vue d'ensemble
Workload Identity est la méthode recommandée pour accéder aux services gcloud depuis GKE. Une fois la liaison établie entre un compte de service Kubernetes et un compte de service Google, tout workload exécuté avec le compte de service Kubernetes s'authentifie automatiquement comme le compte de service Google lors des appels aux API Google Cloud.
Identité inter-clusters : IAM étant global au niveau du projet, le namespace d'identité est partagé entre tous les clusters d'un même projet. Il est donc recommandé de répartir les clusters sur plusieurs projets.
Par exemple :
La commande suivante accorde le même accès à tout cluster du projet qui utilise le compte de service et le Namespace par défaut, et sur lequel Workload Identity est activé :
gcloud iam service-accounts add-iam-policy-binding \ — role roles/iam.workloadIdentityUser \ — member "serviceAccount:[PROJECT_ID].svc.id.goog[default/default]" [GOOGLE_SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.comLimites
- Workload Identity est disponible pour les clusters sous GKE 1.12 ou version ultérieure.
- Lorsque Workload Identity est activé, le compte de service Compute Engine par défaut n'est plus utilisable.
- Workload Identity est incompatible avec les Pods s'exécutant sur le réseau hôte.
- L'injection de namespace Istio ne fonctionne pas avec Workload Identity : elle bascule le serveur de métadonnées vers GCE plutôt que GKE, ce qui aboutit au compte de service Compute GCE.
Activer Workload Identity sur un nouveau cluster
- Vérifiez que l'API IAM Credentials est bien activée
- Définissez l'ID du projet et le nom du cluster
export PROJECT_ID=<project_ID>export CLUSTER_NAME=<cluster_name>export CLUSTER_VERSION=<cluster_version>3. Vous pouvez soit créer un nouveau cluster avec Workload Identity
gcloud beta container clusters create ${CLUSTER_NAME} \ --cluster-version=${CLUSTER_VERSION} \--identity-namespace=${PROJECT_ID}.svc.id.goog
soit mettre à jour un cluster existant :
gcloud beta container clusters update ${CLUSTER_NAME} \ --identity-namespace=${PROJECT_ID}.svc.id.googActiver le serveur de métadonnées
Le serveur de métadonnées s'exécute sur chaque nœud GKE et modifie le comportement de l'endpoint de métadonnées. Il sécurise également cet endpoint et rend inutile le masquage des métadonnées. Activons-le sur notre node pool par défaut.
gcloud beta container node-pools update default-pool \ — cluster=workload-identity-test \ — workload-metadata-from-node=GKE_METADATA_SERVER \ — zone=us-central1-b4. Configurez kubectl pour le cluster
gcloud container clusters get-credentials ${CLUSTER_NAME}
5. Comme la plupart des autres ressources, les comptes de service Kubernetes appartiennent à un Namespace. Créez le Namespace destiné au compte de service Kubernetes :
kubectl create namespace <namespace>6. Définissez le nom du compte de service Kubernetes, le namespace et le nom du compte de service Google :
export K8S_NAMESPACE=<kubernetes_service_account_namespace>export KSA_NAME=<kubernetes_service_account>export GSA_NAME=<google_service_account>7. Créez le compte de service Kubernetes
kubectl create serviceaccount \ --namespace ${K8S_NAMESPACE} ${KSA_NAME}8. Créez le compte de service Google
gcloud iam service-accounts create ${GSA_NAME}9. Créez la liaison entre le compte de service Kubernetes et le compte de service Google
gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:${PROJECT_ID}.svc.id.goog[${K8S_NAMESPACE}/${KSA_NAME}]" \ ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com10. Ajoutez l'annotation iam.gke.io/gcp-service-account=[GSA_NAME]@[PROJECT_ID] au compte de service Kubernetes, en indiquant l'adresse e-mail du compte de service Google :
kubectl annotate serviceaccount \ --namespace ${K8S_NAMESPACE} \ ${KSA_NAME} \ iam.gke.io/gcp-service-account=${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com11. Lancez un pod de test
kubectl run -it \ --generator=run-pod/v1 \ --image google/cloud-sdk \ --serviceaccount ${KSA_NAME} \ --namespace ${K8S_NAMESPACE} \ workload-identity-test12. Vérifiez qu'il s'agit bien du bon compte de service
gcloud auth listRévoquer l'accès
Attention : la révocation n'est pas immédiate. Les tokens en cache peuvent mettre jusqu'à 30 minutes avant d'expirer.
Pour révoquer l'accès, il suffit de supprimer la liaison :
gcloud iam service-accounts remove-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:${PROJECT_ID}.svc.id.goog[${K8S_NAMESPACE}/${KSA_NAME}]" \ ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.comAppliquer le compte de service à un pod via un fichier YAML ou un chart Helm
Utilisez la directive serviceAccountName avec le compte de service Kubernetes employé dans la liaison pour que le pod s'exécute sous le compte de service Google.