Workload Identity Google Cloud: Zugriff ohne Service Account Keys

Definition

Workload Identity Federation ist ein Verfahren, um Workloads über eine externe Identität (z. B. OpenID Connect) Zugriff auf Google Cloud Ressourcen zu geben, ohne Service Account Keys zu verteilen. Es ist keine dauerhafte Schlüsselverwaltung, sondern eine Token-basierte Authentifizierung mit kurzlebigen Anmeldedaten und IAM-gesteuertem Access.

Einleitung

Wenn Builds, Jobs oder Pods auf Google Cloud zugreifen müssen, landen oft schnell Keys in Repos, Secret-Stores oder Images. Workload Identity Google Cloud dreht das Modell um: Der Workload beweist seine Identität über einen Identity Provider, bekommt kurzlebige credentials und arbeitet dann mit klaren IAM-Policies. Das spart Rotations-Aufwand, reduziert Blast Radius und macht Audits deutlich angenehmer.

Die Kernbegriffe: Pools, Provider, Principal Types

Eine Workload identity pool ist der Container für externe identities. Darin definierst du einen workload identity pool provider (die Vertrauensquelle), z. B. OpenID Connect (OIDC) oder SAML V2.0. Über Attribute mapping werden Claims aus dem externen Token in Google-Attribute übersetzt, die du später in IAM nutzen kannst.

Für die Zugriffskontrolle sind Principal Types entscheidend. Du vergibst Rechte nicht „an einen Key“, sondern an definierte Principals, z. B. über principal:// (ein einzelner Principal) oder principalSet:// (eine Menge auf Basis von Attributen). Damit kannst du sehr präzise steuern, welche Workloads auf welche resources zugreifen dürfen.

Architektur: Token Exchange und kurzlebige Credentials

Der Ablauf folgt einem festen Muster. Ein Workload läuft (run) in einer Umgebung wie Kubernetes, GitHub Actions oder einer VM und erhält vom Identity Provider ein OIDC-Token (die assertion). Dieses Token wird beim Google Security Token Service gegen kurzlebige OAuth 2.0 access tokens (federated access tokens) getauscht.

In vielen Setups folgt danach Service account impersonation: Der Workload erhält nicht „direkt“ alle Rechte, sondern darf ein Service Account zeitlich begrenzt impersonieren. Das ist oft die sauberste Trennung zwischen Identität (wo kommt der Workload her) und Berechtigung (was darf er in Google Cloud).

Setup-Schritte: Pools und Provider einrichten

Die Einrichtung passiert typischerweise über Cloud Console, gcloud CLI oder Terraform. Entscheidungsrelevant ist weniger das Tool, sondern die Reihenfolge und die Enge des Trusts.

• Pool anlegen (locations global / global workloadidentitypools) und eindeutige Namenskonventionen festlegen (z. B. pro Team oder Umgebung).
• Provider anlegen: OIDC-Konfiguration (Issuer, JWKS) und Audience sauber definieren; danach Attribute mapping und optional Attribute condition (z. B. Repository-Zulassung via CEL).
• IAM binden: In der Ziel-IAM (meist Service Account) roles/iam.workloadIdentityUser vergeben und die erlaubten Principals über principal:// oder principalSet:// einschränken.

Wichtig: Plane project id und project number, aktiviere notwendige APIs (z. B. IAM Service Account Credentials API) und halte Mappings so minimal wie möglich.

Workloads authentifizieren: GKE, AWS/Azure, GitHub Actions

In GKE ist Workload Identity Federation for GKE der Standardweg, um Kubernetes ServiceAccounts an Google-IAM zu koppeln. Der Nutzen ist praktisch: weniger Secrets auf Node Pools, weniger Drift und klarere Trennung zwischen Cluster- und Cloud-Zugriff.

Für GitHub Actions (oder github gitlab Pipelines) ist das typische Muster: OIDC-Token aus dem Workflow holen, Token Exchange durchführen und dann Cloud APIs aufrufen. Das funktioniert gut mit google-github-actions/auth und lässt sich so einschränken, dass nur ein bestimmtes Repository oder ein bestimmter Workflow Zugriff bekommt.

Für AWS und Azure gilt das gleiche Prinzip: Der Workload bringt seine Identität (z. B. assertion arn oder Azure-managed identity Kontext) mit, Google Cloud prüft sie via Provider, und du vergibst Access über IAM statt über kopierte keys.

IAM-Zugriffskontrollen: Beispiel-Policy-Logik

Ein robustes Muster ist: „Federated Principal darf Service Account impersonieren, und der Service Account hat die fachlichen roles auf die Ziel-resources.“ Damit bleiben Rechte lesbar und wartbar.

• Bindung auf dem Service Account: roles/iam.workloadIdentityUser nur für ein enges principalSet:// (z. B. repo, environment, cluster).
• Fachrechte separat: z. B. Storage- oder Pub/Sub-Rollen nur auf die benötigten Projekte/Resources, nicht global.
• Optional harte Guardrails: constraints/iam.disableServiceAccountKeyCreation, um neue Keys organisatorisch zu unterbinden.

Best Practices, Sicherheitsaspekte, häufige Fallstricke

Der größte Sicherheitsgewinn kommt aus der Kombination: keine statischen credentials, kurze Token-Laufzeiten und enge Attribut-Bedingungen. Halte daher attribute mapping schlank, nutze Attribute condition konsequent und trenne Umgebungen (dev/test/prod) in eigenen Pools oder klaren Attributräumen.

Typische Fehlerbilder: falsche Audience, zu breite principalSet:// Definitionen, unklare Namensräume bei Attributen, fehlende API-Aktivierung oder ein Provider, der „funktioniert“, aber zu viele identities akzeptiert. Troubleshooting läuft am schnellsten über: Token-Inhalt prüfen, Mapping/Conditions prüfen, dann IAM-Bindings und effektive Rechte.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn mehrere Provider (z. B. GitHub plus Azure), mehrere Teams oder regulierte Daten im Spiel sind und du konsistente Guardrails brauchst. Auch wenn ihr von Keys wegmigrieren wollt, ist ein sauberer Plan wichtig, damit am Ende nicht parallel Keys und Federation weiterleben.

Wenn du das Thema zügig und risikoarm aufsetzen willst: Starte mit einem klar abgegrenzten Use Case (z. B. ein GitHub-Workflow oder ein GKE-Namespace), definiere Messbarkeit (weniger Secrets, weniger Rotationsaufwand, weniger Ausnahme-Tickets) und skaliere dann.