Workload Identity Federation in GCP removes long-lived JSON keys from machine-to-machine access. The trade-off is more setup, but the security and operational model is cleaner.
The old pattern was simple, but fragile. A CI/CD tool or third-party system needed access to a GCP project, so the team created a service account, downloaded a JSON key, and stored it as a secret. It worked, but it created a persistent credential that had to be protected, rotated, and audited. If the key expired, every consumer had to be updated. If it did not expire, the blast radius of a leak stayed open-ended.
This is why Workload Identity Federation in GCP matters. It replaces stored secrets with federated identity and short-lived access tokens. Instead of handing credentials to an external system, you define which external identity providers GCP trusts, and under what conditions. The result is a more controlled authentication model for CI/CD, AWS workloads, and other external systems that need to reach GCP.
The design is not lightweight, and that is the point. WIF uses three parts: a workload identity pool, a provider, and a service account binding. The pool groups external identity configurations. The provider defines where the tokens come from and how GCP validates them. The service account binding gives the validated identity real IAM permissions. Compared with a JSON key, this is more ceremony. Compared with long-lived secrets, it removes the operational burden of rotation and storage.
The article makes one thing clear: the team did not migrate everything at once. That would have been a much harder project. Instead, it set a policy for new GCP projects. No new project received a service account key. New deployments used Harness pipelines, GitHub Actions workflows, and AWS Lambda functions through federated identity. That decision moved the problem from an ever-growing secret estate to a bounded model, where the legacy risk stopped expanding.
Implementation depends on the source platform, but the pattern stays the same. Modern CI/CD systems such as GitHub Actions and Harness issue short-lived OIDC JWTs. GCP validates the issuer, maps claims to attributes, and applies a CEL attribute condition as the final gate. The condition matters because it limits which identities are actually allowed through. In multi-org setups, a missing organization check can make the policy too permissive. The article highlights that as a scoping mistake worth watching for.
The AWS case is different. AWS does not use OIDC for these workload tokens. It uses its own STS-based flow. GCP trusts an AWS account, then verifies the identity by calling AWS STS GetCallerIdentity with the signed request provided by the workload. That means GCP is not trusting a label alone. It is asking AWS to prove the identity cryptographically. For architects, that is the key architectural idea: the external platform becomes the proof source, and GCP becomes the verifier.
There is also a useful trade-off in the choice between impersonation styles. Google recommends direct access by default, but the article says the team chose impersonation for some setups. That is a pragmatic choice, not a universal rule. It can add a layer of indirection, but it also fits better when you want GCP permissions to remain attached to a service account boundary rather than to each external identity directly.
The operational result is more stable than the old secret-based model. More than 120 projects were on WIF within six months. The legacy keys did not disappear, but they stopped multiplying. That is often how real infrastructure improvement happens: not by cleaning up every historic edge at once, but by changing the default path so the system slowly becomes safer over time.
For teams running large CI/CD estates, this is the real lesson. Secret-based machine authentication creates hidden work in rotation, auditing, and incident response. Workload Identity Federation shifts that work into upfront trust configuration. It asks for more discipline at setup time, but it reduces long-term operational drag and makes access easier to reason about.