Kubernetes GKE Workload Identity

Capita spesso di dover configurare i servizi Kubernetes affinché utilizzino uno specifico service account Google (in modo simile al progetto kube2iam).

Per ottenere questo risultato basta configurare un service account Kubernetes affinché si comporti come un service account Google: in questo modo, qualsiasi Pod che esegue:

ServiceAccountName: <kubernetes_service_account>

si autenticherà ai servizi gcloud tramite il service account Google.

Nota: si tratta di un prodotto in beta e potrebbe subire modifiche in futuro.

Panoramica:

La workload identity è il metodo consigliato per accedere ai servizi gcloud da GKE. Una volta configurata la relazione tra un service account Kubernetes e un service account Google, qualunque workload eseguito con il service account Kubernetes si autentica automaticamente come service account Google quando accede alle API di Google Cloud.

Identità cross-cluster: è importante tenere presente che, poiché IAM è globale a livello di progetto, l'identity namespace viene condiviso tra tutti i cluster dello stesso progetto: per questo motivo si consiglia di separare i cluster in progetti distinti.

ad esempio:

Il comando seguente concede lo stesso accesso a qualsiasi cluster del progetto che utilizzi il service account e il Namespace di default e su cui sia stata abilitata la Workload Identity:

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

Limitazioni:

• Workload Identity è disponibile sui cluster con GKE versione 1.12 o successiva.
• Quando Workload Identity è abilitato non è più possibile utilizzare il service account di default di Compute Engine.
• Workload Identity non può essere utilizzato con Pod che girano sulla rete dell'host.
• L'iniezione del namespace di Istio non funziona con la workload identity, perché modifica il Metadata server impostandolo su GCE invece di GKE, finendo così per usare il service account di compute GCE.

Abilitare Workload Identity su un nuovo cluster:

1. Verificare di aver abilitato l'API IAM Credentials
2. impostare l'ID del progetto e il nome del cluster

export PROJECT_ID=<project_ID>
export CLUSTER_NAME=<cluster_name>
export CLUSTER_VERSION=<cluster_version>

3. È possibile creare un nuovo cluster con la workload identity

gcloud beta container clusters create ${CLUSTER_NAME} \
  --cluster-version=${CLUSTER_VERSION} \

--identity-namespace=${PROJECT_ID}.svc.id.goog

oppure aggiornare un cluster esistente:

gcloud beta container clusters update ${CLUSTER_NAME} \
  --identity-namespace=${PROJECT_ID}.svc.id.goog

Abilitare il Metadata Server

Il Metadata Server gira su ciascun nodo GKE e modifica il comportamento dell'endpoint dei metadati. Inoltre mette in sicurezza tale endpoint, eliminando la necessità del metadata concealment. Abilitiamo quindi il Metadata Server sul node pool di default.

gcloud beta container node-pools update default-pool \
 — cluster=workload-identity-test \
 — workload-metadata-from-node=GKE_METADATA_SERVER \
 — zone=us-central1-b

4. configurare kubectl per il cluster

gcloud container clusters get-credentials ${CLUSTER_NAME}

5. Come la maggior parte delle altre risorse, i service account Kubernetes risiedono in un Namespace. Creare il Namespace da utilizzare per il service account Kubernetes

kubectl create namespace <namespace>

6. impostare il nome del service account Kubernetes, il namespace e il nome del service account Google

export K8S_NAMESPACE=<kubernetes_service_account_namespace>
export KSA_NAME=<kubernetes_service_account>
export GSA_NAME=<google_service_account>

7. Creare il service account Kubernetes

kubectl create serviceaccount \
 --namespace ${K8S_NAMESPACE} ${KSA_NAME}

8. Creare il service account Google

gcloud iam service-accounts create ${GSA_NAME}

9. Creare il binding tra il service account Kubernetes e il service account 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. Aggiungere l'annotazione iam.gke.io/gcp-service-account=[GSA_NAME]@[PROJECT_ID] al service account Kubernetes, utilizzando l'indirizzo email del service account Google:

kubectl annotate serviceaccount \
  --namespace ${K8S_NAMESPACE} \
  ${KSA_NAME} \
  iam.gke.io/gcp-service-account=${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

11. avviare un pod di test

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

12. verificare che il service account sia quello corretto

gcloud auth list

Revocare l'accesso:

tenere presente che la revoca dell'accesso non è immediata: i token in cache possono impiegare fino a 30 minuti per scadere.

per revocare l'accesso è sufficiente rimuovere il binding:

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

Applicare il service account a un pod in un file YAML o in un Helm chart:

occorre utilizzare la stanza serviceAccountName indicando il service account Kubernetes usato nel binding, così da eseguire il pod con il service account Google.