GCP_CAN_FEDERATE_IDENTITY

Summary

FSProtect ACL Alias

GCP_CAN_FEDERATE_IDENTITY

GCP Alias

Persistence & Impersonation

Affected Object Types

Service Accounts

Exploitation Certainty

Certain

Granting Roles

roles/iam.workloadIdentityUser

Description

GCP_CAN_FEDERATE_IDENTITY indicates that an external identity (e.g., an AWS IAM role, GitHub Actions workflow, or Azure AD managed identity) has been granted roles/iam.workloadIdentityUser on a GCP Service Account via a Workload Identity Federation (WIF) pool. This allows the external identity to exchange its native credential for a short-lived GCP access token that impersonates the target SA.

This edge represents an existing WIF bridge that can be walked across — an attacker who controls the external identity (e.g., compromises the AWS account, GitHub repository, or Azure tenant) can immediately impersonate the bound GCP service account without any GCP credentials.

Key abuse scenarios:

  • Compromise the bound AWS role → exchange AWS STS credentials for GCP SA token.

  • Exploit a GitHub Actions workflow in a repository bound to a WIF pool → run code that authenticates as the GCP SA.

  • Supply-chain attack on a CI/CD pipeline with WIF binding → steal GCP access on every build.

Identification

gcloud CLI

GCP Console

  1. Open GCP ConsoleIAM & AdminWorkload Identity Federation.

  2. For each pool, review the provider configuration (trusted issuer/account).

  3. Open each SA → Permissions → check for Workload Identity User bindings containing pool subjects.

Exploitation

The exploitation path depends on which external identity provider is trusted by the WIF pool binding. In all cases the attacker must first control or compromise the trusted external identity, then perform the STS token exchange below.

GitHub OIDC-backed pool

AWS-backed pool

Compound path: Compromise external identity trusted by WIF pool → exchange for GCP SA token → access all resources the SA can reach (Secret Manager, GCS, IAM) → impersonate further SAs via generateAccessToken.

Persistence: The WIF binding is permanent. Re-compromising any identity trusted by the same pool immediately restores GCP access without requiring IAM changes.

Mitigation

  1. Audit all WIF bindings on service accounts, especially privileged ones.

  2. Use narrow attribute conditions to restrict which external subjects can federate:

  3. Scope WIF bindings to specific subjects rather than entire pools (principalSet://.../* is too broad).

  4. Monitor external identity providers for compromise — if a GitHub repo or AWS account is compromised, all bound GCP SAs are at risk.

  5. Regularly review and rotate WIF pool configurations.

Detection

Log Type
Method
Key Fields

Data Access

GenerateAccessToken (via WIF)

protoPayload.authenticationInfo.serviceAccountDelegationInfo

Alert on:

  • Token exchanges from unexpected external subjects.

  • WIF authentications from repositories or accounts not in an approved allowlist.

  • Token generation for privileged SAs via WIF.

References

  • https://cloud.google.com/iam/docs/workload-identity-federation

  • https://cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation

  • https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform

Last updated

Was this helpful?