Kubernetes GKE Workload Identity

Oft sollen Ihre Kubernetes-Services ein bestimmtes Google-Servicekonto nutzen – ähnlich wie beim kube2iam-Projekt.

Dazu konfigurieren Sie ein Kubernetes-Servicekonto so, dass es als Google-Servicekonto auftritt. Jeder Pod, der mit folgender Angabe läuft:

ServiceAccountName: <kubernetes_service_account>

authentifiziert sich dann bei gcloud-Diensten über das Google-Servicekonto.

Hinweis: Es handelt sich um ein Beta-Produkt – künftige Änderungen sind möglich.

Überblick:

Workload Identity ist der empfohlene Weg, um aus GKE heraus auf gcloud-Dienste zuzugreifen. Sobald Sie die Verknüpfung zwischen einem Kubernetes-Servicekonto und einem Google-Servicekonto eingerichtet haben, authentifiziert sich jeder Workload, der unter dem Kubernetes-Servicekonto läuft, beim Zugriff auf Google-Cloud-APIs automatisch als das Google-Servicekonto.

Cluster-übergreifende Identität: Wichtig dabei: Da IAM projektweit global gilt, wird der Identity Namespace von allen Clustern desselben Projekts gemeinsam genutzt. Es empfiehlt sich daher, Cluster auf separate Projekte aufzuteilen.

Beispiel:

Der folgende Befehl gewährt jedem Cluster im Projekt denselben Zugriff, sofern dieser das Standard-Servicekonto und den Standard-Namespace verwendet und Workload Identity auf dem Cluster aktiviert ist:

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

Einschränkungen:

• Workload Identity steht für Cluster ab GKE-Version 1.12 zur Verfügung.
• Bei aktivierter Workload Identity können Sie das Standard-Servicekonto von Compute Engine nicht mehr verwenden.
• Workload Identity lässt sich nicht für Pods nutzen, die im Host-Netzwerk laufen.
• Istio Namespace Injection funktioniert nicht mit Workload Identity, da der Metadata Server dadurch von GKE auf GCE umgestellt wird – als Ergebnis erhalten Sie ein GCE-Compute-Servicekonto.

Workload Identity auf einem neuen Cluster aktivieren:

1. Stellen Sie sicher, dass die IAM Credentials API aktiviert ist
2. Projekt-ID und Cluster-Namen festlegen

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

3. Sie können entweder einen neuen Cluster mit Workload Identity erstellen

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

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

oder einen bestehenden Cluster aktualisieren:

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

Metadata Server aktivieren

Der Metadata Server läuft auf jedem GKE-Knoten und verändert das Verhalten des Metadata-Endpunkts. Zudem sichert er diesen ab, sodass Metadata Concealment nicht mehr erforderlich ist. Aktivieren wir den Metadata Server auf unserem Standard-Node-Pool.

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

4. kubectl für den Cluster konfigurieren

gcloud container clusters get-credentials ${CLUSTER_NAME}

5. Wie die meisten anderen Ressourcen liegen auch Kubernetes-Servicekonten in einem Namespace. Legen Sie den Namespace für das Kubernetes-Servicekonto an

kubectl create namespace <namespace>

6. Name und Namespace des Kubernetes-Servicekontos sowie den Namen des Google-Servicekontos festlegen

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

7. Kubernetes-Servicekonto erstellen

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

8. Google-Servicekonto erstellen

gcloud iam service-accounts create ${GSA_NAME}

9. Binding zwischen Kubernetes-Servicekonto und Google-Servicekonto erstellen

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. Versehen Sie das Kubernetes-Servicekonto mit der Annotation iam.gke.io/gcp-service-account=[GSA_NAME]@[PROJECT_ID] und nutzen Sie dabei die E-Mail-Adresse des Google-Servicekontos:

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

11. Test-Pod ausführen

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

12. Prüfen, ob das richtige Servicekonto aktiv ist

gcloud auth list

Zugriff entziehen:

Beachten Sie: Der Entzug des Zugriffs greift nicht sofort – zwischengespeicherte Tokens können bis zu 30 Minuten weiter gültig sein.

Um den Zugriff zu entziehen, entfernen Sie einfach das 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

Servicekonto in einer YAML-Datei oder einem Helm-Chart auf einen Pod anwenden:

Nutzen Sie die Anweisung serviceAccountName mit dem Kubernetes-Servicekonto, das Sie im Binding für den Betrieb mit dem Google-Servicekonto verwendet haben.