The migration scenario

A workload runs on Azure. It authenticates against Entra ID (Azure AD) for both user identity and its own service identity. Time to move to GCP. The constraint: Entra ID stays.

Without federation, the migration requires creating GCP service account keys, distributing them, rotating them. The classic key-management nightmare.

With Workload Identity Federation, the GCP workload gets a GCP token by exchanging its Entra ID token. No keys to distribute.

The shape

Workload running on GCP
       │
       ▼
       │ requests Entra ID token (it's an Entra-registered app)
       │
       ▼
       │ exchanges Entra token for GCP token via WIF
       │
       ▼
       │ now has a GCP token; can call GCP APIs as <gcp-service-account>

The GCP service account is bound to the Entra identity via an IAM policy:

# Terraform — link Entra app to a GCP SA
resource "google_iam_workload_identity_pool" "entra" {
  workload_identity_pool_id = "entra-pool"
}

resource "google_iam_workload_identity_pool_provider" "entra" {
  workload_identity_pool_id          = google_iam_workload_identity_pool.entra.workload_identity_pool_id
  workload_identity_pool_provider_id = "entra-provider"

  oidc {
    issuer_uri = "https://login.microsoftonline.com/<tenant-id>/v2.0"
  }

  attribute_mapping = {
    "google.subject" = "assertion.sub"
    "attribute.tid"  = "assertion.tid"
  }
}

resource "google_service_account_iam_member" "binding" {
  service_account_id = google_service_account.workload.name
  role               = "roles/iam.workloadIdentityUser"
  member             = "principal://iam.googleapis.com/projects/.../subject/<entra-app-object-id>"
}

What this gets you

• Zero keys. No service-account JSON files. No rotation. No “did we revoke the leaked key?”
• Centralised identity. Entra ID stays the source of truth. Adding / removing the app’s permissions happens in Entra; the GCP side just enforces.
• Audit clarity. The audit trail on GCP shows the Entra principal that made the call.

What it doesn’t fix

• Network egress. The workload running on GCP calling Entra → cross-cloud. The token-exchange step adds latency (~100-200ms first time; cached after).
• Outage dependency. If Entra is down, the workload can’t refresh its token. Cached tokens last ~1 hour; longer outages stall the workload.
• Per-call cost is small but non-zero. Token exchange is its own API call.

The migration sequence

For one client we did:

1. Week 1. Register the workload in Entra (it was already there for user-auth; add a new app reg for the service identity).
2. Week 2. Set up the GCP Workload Identity Pool + Provider + Binding via Terraform.
3. Week 3. Update the workload’s auth library to use WIF (one config change).
4. Week 4. Deploy to GCP staging; validate; deploy production.

Four weeks of light-touch work; zero key-management infrastructure to maintain.

When to use it

• Workload on GCP authenticating against external IdP (Entra, Auth0, Okta) — primary use case.
• Workload on AWS authenticating against external IdP — same pattern, AWS calls it “Web Identity Federation.”
• Workload on GCP authenticating against another GCP project — use IAM directly, not WIF.

For migrations where the IdP isn’t moving, WIF is the bridge. For new GCP-only deployments, GCP-native identity is simpler.

The fewer keys you manage, the fewer keys you can leak. WIF removes a whole class of keys.