What is Workload Identity Federation?

Definition

Workload Identity Federation (WIF) is a Google Cloud feature that allows external workloads (running outside Google Cloud — in AWS, Azure, GitHub Actions, GitLab, Kubernetes, on-premises, etc.) to authenticate to Google Cloud using their existing identity, then impersonate a service account to call Google Cloud APIs.

It eliminates the need to create, distribute, and manage service account keys for external workloads.

In simple terms:

Workload Identity Federation = trade your external identity (OIDC token, SAML assertion, AWS credentials) for short-lived Google Cloud access — no keys required.

---

Why It Matters

• Service account keys are the #1 cause of GCP credential leaks (committed to Git, leaked in logs, copied to dev machines).
• WIF enables external workloads to authenticate without keys, eliminating the leak surface.
• Provides short-lived credentials with full audit attribution.
• Required pattern in modern CI/CD security.

---

How It Works

1. External workload presents its native identity (OIDC token, SAML, AWS credentials).
2. Workload Identity Pool / Provider in Google Cloud validates the assertion.
3. Attribute mapping / conditions translate external identity claims into Google Cloud principal attributes.
4. Service account impersonation issues short-lived Google Cloud credentials.
5. Workload uses those credentials to call Google Cloud APIs.

Components

• Workload Identity Pool — container for federated identities (per project).
• Workload Identity Pool Provider — defines the external IdP (OIDC, AWS, SAML).
• Attribute mapping — translates external claims (google.subject, attribute.repository, etc.).
• Attribute condition — restricts which external identities are allowed.
• Service account — granted roles/iam.workloadIdentityUser for impersonation.

---

Supported External Identity Providers

• OIDC: GitHub Actions, GitLab, CircleCI, Buildkite, Auth0, Kubernetes ServiceAccount tokens, Microsoft Entra ID (formerly Azure AD) via OIDC, etc.
• SAML: Various enterprise IdPs.
• AWS: AWS STS-based federation.
• Azure: Microsoft Entra ID via OIDC.

---

Common Patterns

GitHub Actions

- uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: 'projects/123/locations/global/workloadIdentityPools/github/providers/oidc'
    service_account: '[email protected]'

GitHub Actions issues OIDC token; WIF validates; impersonates cicd-sa for the workflow run. No stored secrets.

Attribute Condition (Strict Trust)

attribute.repository == "myorg/myrepo" &&
attribute.repository_owner == "myorg" &&
attribute.ref == "refs/heads/main"

Only main branch of one repo can authenticate.

AWS Workloads Authenticating to GCP

EC2 / Lambda / EKS workload uses its AWS credentials → WIF validates against AWS provider → impersonates GCP service account.

Azure Workloads

Azure VM / Function / AKS uses its Managed Identity → OIDC token → WIF → impersonates GCP service account.

On-Prem Kubernetes

Kubernetes ServiceAccount JWT → WIF (OIDC provider trusting cluster's issuer) → impersonates GCP service account.

---

Benefits

• No long-lived keys.
• Short-lived credentials (1 hour default).
• Full audit trail (impersonation logged with external identity attributes).
• Reduced operational overhead (no key rotation).
• Consistent identity model across CI/CD, multi-cloud, and on-premises.

---

Common Mistakes

• Weak attribute condition allowing any GitHub repo / any branch to authenticate.
• No condition at all — public OIDC providers (e.g., GitHub) trusted globally.
• Service account too broad — impersonated SA has Owner role.
• roles/iam.workloadIdentityUser granted at project level (rather than per-SA).
• Pool / provider sprawl — many pools without governance.

---

Real-World Examples

1. Wide-Open GitHub Provider

WIF provider trusted GitHub OIDC issuer with no attribute condition. Any GitHub repo could authenticate to the pool. Attacker created a public repo, ran a workflow, impersonated the cicd SA. Fix: strict attribute.repository condition.

2. CI/CD Migration

Team replaced 80+ service account keys stored across CI providers with WIF + impersonation. Eliminated key rotation chores; reduced incidents.

3. Multi-Cloud Authentication

Company runs workloads in AWS and GCP. AWS workloads authenticate to GCP via WIF + AWS provider; no cross-cloud keys.

4. On-Prem Kubernetes Cluster

Team's on-premises k8s cluster used hard-coded SA keys for GCP access. Migrated to WIF with the cluster's OIDC issuer; eliminated keys.

---

Best Practices

1. Always use strict attribute conditions — never trust a federation provider without scoping.
2. GitHub: condition on attribute.repository, attribute.repository_owner, ideally attribute.ref / attribute.environment.
3. GitLab: condition on project ID / branch / environment.
4. Per-pool, per-provider, per-SA rather than monolithic.
5. Service accounts impersonated with least privilege.
6. Short token lifetimes.
7. Audit log review — track which external identities are impersonating which SAs.
8. Periodic provider review — remove stale CI/CD providers.
9. Org Policy to disable service account key creation (forces federation adoption).
10. Document each pool and provider with owner / purpose.

---

Checklist

• WIF used in CI/CD instead of keys?
• Attribute conditions strict (not wide-open)?
• SAs impersonated with least privilege?
• Pools / providers documented per workload?
• roles/iam.workloadIdentityUser per-SA, not project-level?
• Audit logs centralized, alerts on unusual federation events?
• Org Policy disabling SA key creation where appropriate?
• Quarterly review of providers and bindings?

---

How Forestall Helps

Forestall identifies:

• Service account keys that can be replaced by WIF.
• WIF pools and providers with weak attribute conditions.
• External identities with paths to high-privilege SAs.
• Federation governance gaps (stale providers, broad bindings).

---

Frequently Asked Questions

Is WIF only for CI/CD?

No — also for AWS, Azure, on-premises Kubernetes, OIDC apps, SAML IdPs.

Does WIF work with GitHub Enterprise Server?

Yes — configure provider with the GHES OIDC issuer URL.

How does WIF compare to AWS IRSA?

Conceptually similar — both federate workload identities to cloud IAM without long-lived keys.

Can I use WIF and SA keys together?

Yes, but the goal is to eliminate keys. Migrate workload by workload.

What's the difference between Workload and Workforce Identity Federation?

Workload = non-human (CI/CD, workloads). Workforce = human users from external IdP for Google Cloud access.

---

Conclusion

Workload Identity Federation is the modern way to authenticate external workloads to Google Cloud. It eliminates service account keys, provides short-lived credentials, and improves auditability. Configure pools and providers with strict attribute conditions, scope service account impersonation tightly, and migrate every external workload off keys. The result is a far smaller credential-leak surface and a cleaner cloud identity model.