Moving Beyond Long-Lived Keys: How Organizations Scale Federated Identity in Google Cloud

The traditional path to giving external systems access to Google Cloud Platform is straightforward: create a service account, download a JSON key, and store it as a secret. It works, but it introduces lasting operational friction. Keys sit in environment variables, secret stores, and sometimes—when someone slips up—in version control. Rotating them means tracking down every team that holds a copy. Many organizations skip rotation entirely, leaving open-ended credentials exposed indefinitely.

Workload Identity Federation (WIF) inverts this model entirely. Instead of managing secrets, you declare which external identity providers you trust and under what conditions. When a workload needs access, it presents its own native token; GCP validates it and issues a short-lived access token that expires when the job finishes. No key storage, no rotation, no audit trail uncertainty.

How WIF Works in Three Pieces#

The mechanism has three required components, each essential but useless alone:

• Workload Identity Pool: A named container in your GCP project that groups external identity configurations.
• Provider (or connector): Defines the actual trust. It specifies where tokens come from, how to validate them, which external claims map to GCP attributes, and what identities are allowed through.
• Service Account Binding: Once an external identity passes validation, it binds to a service account and temporarily inherits that account's IAM permissions.

The philosophical shift is meaningful: a service account key is a secret you own and protect forever; a federated identity is a trust relationship you declare once and never handle again.

Scaling Adoption Without Migration Risk#

Rolling out WIF organization-wide could mean retrofitting hundreds of existing keys—coordinating across teams, managing outage risks, and proving each legacy key is genuinely dead rather than merely unused. That path is both difficult and dangerous.

Instead, the simpler approach: draw a line at creation time. WIF became mandatory for every new GCP project as part of a broader cloud modernization initiative. No new project received a service account key; all deployments used federated identity through Harness, GitHub, or other CI/CD platforms. This requirement was baked into project provisioning rather than left to individual teams to opt into.

Within six months, over 120 projects were authenticating via WIF. The legacy keys didn't disappear, but they stopped multiplying. The problem reframed from an ever-growing attack surface into a fixed and shrinking one. As a bonus, mandating the pattern early meant all projects inherited the same scoping conventions, so each new integration became a copy of an already-trusted configuration rather than a fresh design decision.