Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Workload Identity Kubernetes sur GKE

By Ami MahloofOct 11, 20193 min read

Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.

1 1f14dqe9np6kalf53ha4kq

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).

1 9i9730xcxt2drqhbkrszcw

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.com

Limites

  • 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

  1. Vérifiez que l'API IAM Credentials est bien activée
  2. 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.goog

Activer 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-b

4. 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.com

10. 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.com

11. Lancez un pod de test

kubectl run -it \
--generator=run-pod/v1 \
--image google/cloud-sdk \
--serviceaccount ${KSA_NAME} \
--namespace ${K8S_NAMESPACE} \
workload-identity-test

12. Vérifiez qu'il s'agit bien du bon compte de service

gcloud auth list

Ré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.com

Appliquer 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.