Workload Identity für GKE: Häufige Fehlkonfigurationen

Der GKE Workload Identity Analyzer von DoiT prüft in GKE laufende Workloads und stellt sicher, dass Workload Identity korrekt konfiguriert ist.

workload-identity-for-gke (1)

Mit dem GKE Workload Identity Analyzer zur sauberen Konfiguration

Wer Google Kubernetes Engine (GKE) einsetzt und seine Workloads mit anderen Diensten in Google Cloud kommunizieren lässt, nutzt mit hoher Wahrscheinlichkeit Workload Identity. Falls noch nicht: Es lohnt sich. Google empfiehlt Workload Identity für Workloads auf Google Kubernetes Engine (GKE) als sicheren und gut verwaltbaren Weg, um auf Google-Cloud-Dienste zuzugreifen.

Alternativen zu Workload Identity

Als alternative – und teils veraltete – Wege zur Authentifizierung zwischen GKE und Google Cloud kommen infrage:

der Compute Engine Default Service Account, dessen Scope in der Regel zu weit gefasst ist und sich nicht je Workload anpassen lässt
das Einbinden von Service-Account-Secrets in Ihre Workloads – ein Sicherheitsrisiko, da diese Secret Keys langlebige Credentials sind, die sorgfältig gepflegt und gelegentlich rotiert werden müssen, um den Security Best Practices zu entsprechen

So funktioniert Workload Identity

Workload Identity bringt keine dieser Schwächen mit: Die Konfiguration erfolgt pro Workload, und es müssen weder Secrets verwaltet noch in den Workload eingeschleust werden.

Im Kern wird eine Verknüpfung zwischen einem Kubernetes Service Account (KSA) und einem Google Service Account (GSA) aufgebaut. Der KSA weist Ihren in GKE laufenden Workload als Nutzer des GSA aus, und der GSA wiederum erhält die nötigen Berechtigungen für Google-Cloud-Ressourcen. Die Zugriffsrechte können so weit oder so eng gefasst sein, wie es der Workload erfordert – etwa ein Workload, der Zugriff auf alle PubSub-Topics in einem Projekt benötigt, im Vergleich zu einem Workload, der nur ein einzelnes (oder einige wenige) ansprechen muss.

Die Vorteile von Workload Identity liegen auf der Hand, doch der Einsatz erfordert etwas Einrichtungsaufwand, der anfangs verwirrend sein kann.

Fehlkonfigurationen können an vielen Stellen in der Authentifizierungskette zwischen einem in GKE laufenden Pod und einem Service in einem GCP-Projekt auftreten. Die Fehlersuche wird dadurch schnell mühsam.

Was der GKE Workload Identity Analyzer leistet

Genau dafür hat DoiT den GKE Workload Identity Analyzer entwickelt. Das Kommandozeilen-Tool Workload Identity (WI) Analyzer erwartet einen Pod-Namen als Argument und führt eine Reihe von Konfigurationsprüfungen durch, um sicherzustellen, dass WI für Ihren Workload korrekt eingerichtet ist. Geprüft wird:

ob Workload Identity auf dem GKE-Cluster aktiviert ist
ob im Pod .spec.serviceAccountName gesetzt ist
ob der KSA (aus dem vorherigen Schritt) existiert
ob der KSA korrekt mit einem GSA annotiert ist
ob der GSA (aus dem vorherigen Schritt) im Projekt existiert
ob der KSA die Rolle roles/iam.workloadIdentityUser auf dem GSA besitzt

Abschließend ermittelt und listet das Tool sämtliche IAM-Rollen, die der GSA im Projekt besitzt (Hinweis: IAM-Rollen, die in einem engeren Scope vergeben wurden – etwa auf einer einzelnen GCP-Ressource wie einem PubSub-Topic, einer CloudSQL-Instanz usw. – werden dabei nicht berücksichtigt).

Der Lauf dauert weniger als 10 Sekunden und erspart viel Klickerei in der Konsole oder Tipparbeit im Terminal.

Das Tool ist in Python geschrieben und auf PyPI veröffentlicht. Die Installation läuft bequem über PIP:

$ pip install wi-analyzer

GKE Workload Identity Analyzer ausführen

Die Voraussetzungen für die Ausführung sind:

gcloudcli installiert und konfiguriert
Application Default Credentials, erzeugt über gcloud
kubectl installiert und mit Cluster-Zugriff konfiguriert

Beachten Sie: Das Tool leitet einige Informationen aus Ihrem aktuellen kubeconfig-Kontext ab. Außerdem erwartet es den standardmäßig generierten Namen für einen GKE-Cluster beim Abrufen der Credentials (im Format: gke_<GCP_PROJECT_ID>__<CLUSTER_NAME>).

Alternativ lassen sich GCP-Projekt-ID, Cluster-Location und Cluster-Name als Argumente übergeben.

Sobald alles steht, können Sie das Tool im Terminal starten:

$ wi-analyzer --help
usage: wi-analyzer [-h] [-n NAMESPACE] [-d] pod

GKE Workload Identity Analyzer

positional arguments:
  pod                   Kubernetes Pod name to check

options:
  -h, --help            show this help message and exit
  -n NAMESPACE, --namespace NAMESPACE
                        Kubernetes Namespace to run in
  -p PROJECT, --project PROJECT
                        GCP Project holding the cluster
  -l LOCATION, --location LOCATION
                        The GCP location of the cluster
  -c CLUSTER, --cluster CLUSTER
                        The name of the cluster

  -d, --debug           Enable debug logging

Angenommen, ich folge der Dokumentation zur Konfiguration meines Workloads für WI und übersehe dabei versehentlich einen trivialen Schritt. Die Ausgabe des Tools kann hier weiterhelfen:

$ wi-analyzer demo-pod
Check results
---------------------------
V=Passed, X=Failed, -=Skipped

[V] GCP project and GKE info determined from current context
[V] Namespace passed as argument,or determined from current context
[V] Workload Identity enabled on GKE Cluster
[V] Pod found in current context
[V] GKE Node found in the cluster
[V] Workload Identity enabled on Node Pool
[V] KSA found in the cluster
[X] KSA Workload Identity annotation set correctly
[-] GSA found in GCP project
[-] GSA is enabled
[-] GSA has Workload Identity users configured
[-] GSA does not have KSA as a Workload Identity user

GKE cluster info
---------------------------
Cluster: "projects/test-eyal/locations/europe-west1-b/clusters/playground"
Workload: "demo/demo-pod" running on Node: "gke-playground-nodepool-1f1ace09-96kr"
KSA name: "demo-ksa"

Google Service Account info
---------------------------
Google Service Account information could not be determined, fix previous issues

Wie die Ausgabe zeigt, fehlte die WI-Annotation am KSA. Nach der Korrektur sollte ein erneuter Lauf nur noch erfolgreiche Checks und die vollständige Übersicht anzeigen:

$ wi-analyzer demo-pod
Check results
---------------------------
V=Passed, X=Failed, -=Skipped

[V] GCP project and GKE info determined from current context
[V] Namespace passed as argument,or determined from current context
[V] Workload Identity enabled on GKE Cluster
[V] Pod found in current context
[V] GKE Node found in the cluster
[V] Workload Identity enabled on Node Pool
[V] KSA found in the cluster
[V] KSA Workload Identity annotation set correctly
[V] GSA found in GCP project
[V] GSA is enabled
[V] GSA has Workload Identity users configured
[V] GSA does not have KSA as a Workload Identity user

GKE cluster info
---------------------------
Cluster: "projects/test-eyal/locations/europe-west1-b/clusters/playground"
Workload: "demo/demo-pod" running on Node: "gke-playground-nodepool-1f1ace09-96kr"
KSA name: "demo-ksa"

Google Service Account info
---------------------------
Google Service Account: "projects/test-eyal/serviceAccounts/[email protected]"
Has the following Workload Identity Users:
serviceAccount:test-eyal.svc.id.goog[demo/demo-ksa]

GSA: "[email protected]" has the following roles in project "test-eyal":
roles/cloudsql.client
Workload Identity configured properly - check if any IAM roles are missing from the list above

Aktuell unterstützt das Tool nur GKE Standard, doch Fleet Workload Identity (GKE WI für Anthos) steht auf der Roadmap. Tests auf Multi-Cloud-Anthos-Clustern laufen bereits, erfordern aber einige grundlegende Änderungen am Tool. Bleiben Sie dran!

Sie sind auf ein Problem gestoßen oder haben Ideen für neue Features?

Melden Sie sich gerne – entweder hier in den Kommentaren oder über ein Issue im GitHub-Repository.