Workload Identity Federation — keyless auth from AWS and GitHub

Workload Identity Federation (WIF) enables external workloads — applications running on AWS, Azure, GitHub Actions, GitLab CI, Kubernetes clusters outside GCP, or any OIDC-compatible identity provider — to authenticate to GCP APIs and impersonate GCP service accounts without storing long-lived GCP service account keys. The core mechanism is OIDC or SAML 2.0 token exchange: the external workload presents a short-lived token from its native identity provider, and GCP exchanges it for a short-lived GCP access token, eliminating the static key credential that represents the highest-risk exfiltration target in GCP IAM.

The security improvement from WIF over service account keys is categorical, not incremental. A service account key is a long-lived, downloadable JSON credential that retains full permissions until explicitly revoked. If leaked in a git commit, log file, container image, or CI/CD pipeline variable, the key provides persistent access until discovered and rotated. A WIF-issued access token is valid for one hour and is bound to the specific workload’s OIDC claims; it cannot be reused from a different context, and there is no long-lived credential to leak in the first place.

WIF is the mechanism enabling true keyless authentication for all three major cross-cloud scenarios encountered in Course 5: authenticating from an AWS Lambda function to a GCP API in a multi-cloud architecture, authenticating from a GitHub Actions workflow to GCP for automated deployments, and authenticating from a GitLab CI pipeline to GCP for container image pushes to Artifact Registry. Understanding WIF’s configuration model — workload identity pools, providers, and service account impersonation — is the prerequisite for implementing any of these keyless cross-cloud patterns.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.