GKE Workload Identity heißt jetzt Workload Identity Federation – was hat sich sonst geändert?

WIF ist ein Feature, das die Lücke zwischen externen Identitätssystemen und Google Cloud IAM schließt. Es erlaubt Unternehmen, ihre bestehende Identitätsinfrastruktur – etwa Active Directory, AWS, Okta und weitere – nahtlos auf Google-Cloud-Ressourcen auszuweiten.

Indem WIF Vertrauensbeziehungen zwischen externen Identity Providern (IdP) und Google Cloud IAM aufbaut, können Nutzer und Anwendungen, die über andere Systeme als GCP authentifiziert sind, mit ihren bestehenden Identitäten auf GCP-Ressourcen zugreifen.

Für diese Vertrauensbeziehung legen Sie zunächst einen Workload Identity Pool an, der die externen Identitäten verwaltet, und fügen anschließend Workload Identity Providers hinzu, die jeweils die Beziehung zwischen Ihrem IdP und GCP beschreiben.

Sobald die Beziehung steht, kann ein Credential-Token Ihres IdP über den Security Token Service von Google verifiziert und gegen ein föderiertes Token zur Authentifizierung bei GCP eingetauscht werden.

Bei Workload Identity Federation for GKE (zuvor schlicht Workload Identity) übernimmt Google die Verwaltung von Pool und Provider für Sie.

Jedes GCP-Projekt verfügt über einen einzigen, festen Pool (PROJECT_ID.svc.id.goog); sobald das Feature auf einem GKE-Cluster aktiviert ist, wird der Cluster als Identity Provider in diesem Pool registriert.

Der GKE Metadata Server wird dann automatisch als DaemonSet auf allen Cluster-Nodes ausgerollt. Er fängt unter anderem Anfragen Ihrer workloads ab und antwortet mit dem passenden Token für den Service Account, dessen Identität Ihr Workload annehmen soll.

Genau darum geht es bei diesem Feature im Kern: Ihren GKE-workloads Zugriff auf GCP-Ressourcen zu verschaffen, ohne explizite Credentials zu übergeben oder den IAM Service Account des darunterliegenden Nodes zu nutzen.

Im ersten Schritt aktivieren Sie WIF auf Ihrem GKE-Cluster und den Node-Pools, falls noch nicht geschehen. Dieser Schritt ist gut dokumentiert und nicht Gegenstand dieses Beitrags.

Anschließend legen Sie einen Kubernetes Service Account (KSA) an, den Ihr Workload verwendet (konfiguriert in der Pod-Spec).

Mit Workload Identity (WI) können Sie Ihren workloads dann auf zwei Wegen GCP-IAM-Berechtigungen erteilen:

Über Impersonation eines Google IAM Service Accounts

Bis vor Kurzem war dies der Standardweg und die einzige Möglichkeit, WI zu konfigurieren; mittlerweile ist er als alternativer Weg dokumentiert.

Kurz gesagt: Sie erstellen ein Google Service Account (GSA) und versehen es mit allen IAM-Berechtigungen, die Ihr Workload benötigt. Anschließend richten Sie ein Binding zwischen GSA und KSA ein, indem Sie den KSA zum roles/iam.workloadIdentityUser des GSA machen und den KSA entsprechend annotieren.

Über IAM-Principal-Identifier

Das ist die wesentliche Neuerung, die in der Einleitung erwähnt wurde: Kubernetes-Ressourcen lassen sich direkt in IAM-Policies als Principals referenzieren.

Sie können Ihren KSA per Name (für Identity Sameness) oder per UID ansprechen (nach der Erstellung in der KSA-Spec verfügbar).

Sie können sogar alle Pods in einem Cluster adressieren, falls eine bestimmte IAM-Berechtigung von all Ihren workloads benötigt wird.

Quelle: https://twitter.com/_techcet_/status/1773865010651173293

Wie die Tabelle oben zeigt, hat sich die Konfiguration deutlich vereinfacht, seit sich Kubernetes-Ressourcen direkt als IAM-Principals adressieren lassen.

Statt zusätzlich ein GSA zu pflegen und daran zu denken, dem KSA die Impersonation-Berechtigung zu erteilen (ein Schritt, der gerne vergessen wird), weisen Sie die nötigen IAM-Rollen direkt dem KSA zu. Auch die Annotation des KSA mit dem GSA-Namen entfällt – ein weiterer Schritt, der schnell falsch konfiguriert oder schlicht vergessen wurde.

Dass sich ein KSA per UID statt per Name referenzieren lässt, ist eine sehr willkommene Ergänzung und senkt das Risiko, durch Identity Sameness versehentlich Zugriff für unerwünschte workloads zu gewähren. Andererseits kann Identity Sameness, gezielt eingesetzt, durchaus nützlich sein – und steht aktuell in beiden Konfigurationsvarianten zur Verfügung.

Hinzu kommt die Möglichkeit, alle Pods in einem Cluster als IAM-Principal-Set zu referenzieren – ein praktisches Feature, das mehr Flexibilität schafft. Ich gehe davon aus, dass in den kommenden Monaten Support für weitere Kubernetes-Ressourcen als IAM-Principals folgen wird (Namespaces wären eine großartige Ergänzung).

Eine Einschränkung beim Einsatz von IAM-Principals: Es gibt nach wie vor einige Services, die entweder nicht unterstützt werden oder sich noch in der Preview befinden. Falls Sie WI aktuell für den Zugriff auf einen dieser Services nutzen, sollten Sie mit dem Upgrade Ihrer Konfiguration noch warten.

Die gute Nachricht: Sie müssen nicht – die GSA-Impersonation wird weiterhin unterstützt und wird meines Erachtens auch nicht so bald verschwinden.

IAM-Principals vereinfachen die Konfiguration jedoch und bringen die im vorherigen Abschnitt genannten Vorteile mit, weshalb ich die Umstellung empfehle, wo immer möglich.

Wie lassen sich Ihre workloads möglichst reibungslos von der bestehenden Konfiguration auf IAM-Principals umstellen?

Angenommen, Sie nutzen aktuell Workload Identity für den Zugriff auf GCP-Ressourcen, dann existiert ein GSA mit den nötigen IAM-Berechtigungen sowie ein KSA, der die IAM-Rolle Workload Identity User für dieses GSA hat.

Schließlich ist Ihr KSA so annotiert, dass er auf das GSA verweist, etwa so:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
  ...

Schauen wir, ob sich die WI-Konfiguration mit "Zero Downtime" aktualisieren lässt.

Zuerst starten wir einen Pod, der diesen KSA für ein paar Tests nutzt:

$ echo 'apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
spec:
  serviceAccountName: <KSA_NAME>
  containers:
  - image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    name: workload-identity-test' | kubectl apply -f -

Sobald der Pod läuft, steigen wir per Exec ein:

$ kubectl exec -ti token-test -- bash

Aus dem Pod heraus richten wir eine Anfrage an den Metadata Server, um zu sehen, welche Identität unser Pod gerade nutzt:

root@token-test:/# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
{"aliases":["default"],"email":"<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com","scopes":["https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/userinfo.email"]}

Am Feld email in der Antwort erkennen wir, dass unsere Identität dem GSA entspricht, das unser KSA verwendet (über die Annotation am KSA).

Was passiert, wenn wir diese Annotation vom KSA entfernen?

# wird außerhalb des Pods ausgeführt
$ kubectl annotate serviceaccount <KSA_NAME> iam.gke.io/gcp-service-account-

Wir wiederholen die Anfrage:

root@token-test:/# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
{"aliases":["default"],"email":"<PROJECT_ID>.svc.id.goog","scopes":["https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/userinfo.email"]}

Wie zu sehen ist, wechselt unsere Identität sofort zum Workload Identity Pool des Projekts. Damit sollte der Wechsel von GSA-Impersonation zum IAM-Principal-Binding ohne Pod-Neustart funktionieren (Hinweis: Bestimmte Clients können dennoch einen Neustart brauchen, um die neue Identität zu übernehmen).

Vorausgesetzt, Ihr KSA ist weiterhin mit dem GSA annotiert und der Workload läuft:

1. Erstellen Sie eine IAM-Policy, die die nötigen IAM-Rollen direkt dem KSA zuweist (dieselben Rollen, die Ihr GSA hatte).
2. Entfernen Sie die WI-Annotation vom KSA. Ab diesem Moment sollte der Pod sofort die Berechtigungen nutzen, die dem KSA-Principal erteilt wurden (treten Fehler auf, hilft ein Pod-Neustart).
3. Sobald alles bestätigt läuft, können Sie das nun überflüssige GSA aufräumen und sicherstellen, dass Ihr IaC und Ihre Manifests auf dem aktuellen Stand sind.