GCP Architecture Series #45 — Workload Identity for GKE

Business Challenge

#43 and #44 federated with identity providers you do not control. This one Google runs for you, which removes three classes of mistake and introduces a different one.

Architecture

In most cases, Workload Identity Federation for GKE is the recommended way for workloads on GKE to reach Google Cloud services. The reason it is simpler than #43 and #44 is one sentence: in GKE, Google Cloud manages the workload identity pool and provider for you, and does not require an external identity provider.

What enabling it creates

• A fixed workload identity pool for the project, named PROJECT_ID.svc.id.goog. Note the scope in the name: project, not cluster.
• The cluster registered as an identity provider inside that pool.
• The GKE metadata server, which intercepts credential requests from workloads, on every node.

And it persists: GKE does not delete this workload identity pool even if you delete all of the clusters in your project. The pool outlives the clusters, which matters because the grants you wrote against it outlive them too.

The credential flow

Four steps, and the interesting part is who signs what:

1. Application Default Credentials asks the Compute Engine metadata server for a token — the workload does nothing special.
2. The GKE metadata server intercepts, and asks the Kubernetes API server for a Kubernetes ServiceAccount token that identifies the requesting workload. That JWT is signed by the API server.
3. The metadata server uses Security Token Service to exchange the JWT for a short-lived federated access token.
4. The workload uses it, with whatever the principal identifier can reach.

So the trust chain ends at the Kubernetes API server's signature. That is the thing GKE can vouch for and an external provider cannot, and it is why none of #44's issuer problems arise here.

Four identifiers, and one of them is wider than it reads

Name or UID, for the third time in this block

GKE offers both, and the choice is the one from #43 and #44 in new clothes. Select the ServiceAccount by name and a deleted-and-recreated ServiceAccount with the same name in the same namespace inherits the grant. Select the ServiceAccount by UID and it does not, because the UID is a different object.

Which is right depends on what you mean. A grant to ns/prod/sa/database-reader is a statement about a role in the system that should survive a redeploy — and redeploys recreate ServiceAccounts routinely, so the name is usually correct here. That is the opposite conclusion from #44, where the GitHub organisation name was the risky choice. The difference is who controls the namespace: your own cluster manifests, versus a public registry where somebody else can claim a released name.

Why This Architecture Holds Up

Both are quiet, and both produce a working system that is not the one you configured.

Host network Pods. A Pod with hostNetwork: true does not use Workload Identity Federation for GKE at all — GKE automatically routes requests from these Pods to the Compute Engine metadata server. It therefore authenticates as the node's service account, with whatever that can do. Nothing errors, nothing warns; the Pod simply has a different identity from its neighbours in the same namespace. This is #41's attached-service-account problem in a new location: a workload inside the machine becomes the machine.

The first few seconds. The GKE metadata server takes a few seconds to start accepting requests on a newly created Pod, so attempts to authenticate within the first few seconds of a Pod's life might fail. That is a startup race, not a permissions problem, and it presents as an intermittent auth failure on cold starts — the kind of thing that gets diagnosed as a flaky IAM grant and papered over with a retry nobody documents.

There is also a capacity ceiling worth knowing before it surprises you: the Exchange Token API in Security Token Service has a quota limit of 6,000 requests per minute. Every Pod authenticating is an exchange, so a large cluster with short-lived Pods and no token caching can reach that, and the failure will look like an identity problem rather than a quota one.

What to do with this

1. Prefer the ServiceAccount identifier to the namespace one. The namespace identifier is a project-wide grant wearing a cluster-shaped name.
2. Use the cluster identifier when you mean a cluster. It exists precisely so the namespace one does not have to be misused for it.
3. Audit Pod specs for hostNetwork: true as part of an access review, not a networking one.
4. Keep the node service account, minimised. Image pulls still use it.
5. Expect a cold-start race and let the client library retry rather than treating it as a grant failure.
6. Remember the pool outlives the clusters. Deleting every cluster leaves the pool and the grants written against it in place.

Key Architecture Decisions

Closing Thought

Three posts of federation have moved the same risk around rather than removing it. With AWS, Google verifies the credential by asking AWS, and the boundary comes free. With GitHub, the issuer proves almost nothing and the boundary is a CEL expression you have to remember. With GKE, Google Cloud manages the pool and provider itself, the API server's signature is the trust, and there is nothing to map or condition — so the risk reappears as a naming question: which of four identifiers did you use, and how wide is it really.

The namespace identifier is the one to be careful with, and it is careless in a specific way. It reads like a Kubernetes concept and behaves like a project-wide one, because the pool it lives in belongs to the project and every cluster registers into the same pool. Kubernetes encourages reusing namespace names across clusters — that is the whole point of namespaces — so the identifier is at its most dangerous in exactly the estates that are organised well. That has been the recurring shape of this block: the better the convention, the wider the grant that follows it.

Official Google Cloud Reference

• About Workload Identity Federation for GKE
• Configure Workload Identity Federation for GKE
• Workload Identity Federation
• Principal identifiers
• Service account impersonation
• Overview of IAM Conditions