Configure GitHub Actions OIDC authentication to Google Cloud Platform with Workload Identity Federation, restricting token claims to a specific repository and branch
Create a GCP Workload Identity Pool and a Provider of type OIDC pointing to https://token.actions.githubusercontent.com as the issuer; set the audience to the custom audience string that matches what the GitHub Actions OIDC token action will request
Define attribute mappings in the provider that map Google's attribute to the OIDC assertion: google.subject = assertion.sub, attribute.repository = assertion.repository, and attribute.ref = assertion.ref so these claims are available for IAM conditions
Bind an IAM service account to the Workload Identity Pool member using the principalSet format with conditions: request.auth.claims.attribute.repository == 'org/repo' && request.auth.claims.attribute.ref == 'refs/heads/main' to restrict token exchange to the specific repo and branch
In the GitHub Actions workflow, set permissions: id-token: write and use the google-github-actions/auth action with workload_identity_provider pointing to the provider resource name and service_account set to the bound service account email
Validate the authentication by running gcloud auth list in a subsequent step and asserting the active account matches the expected service account email before proceeding with any GCP API calls
Add a separate IAM binding for pull request workflows that maps attribute.ref == 'refs/pull/*/merge' and grants only storage.objectViewer permissions, enabling read-only CI checks on PRs without deployment access
Known gotchas
The audience value configured on the GCP OIDC provider must exactly match the audience passed in the GitHub Actions auth step; a mismatch causes the token exchange to fail with an audience validation error that is not clearly reported in the GitHub Actions log
Attribute conditions on the IAM binding use attribute values from the assertion after mapping; if the attribute mapping is missing or incorrectly named, the condition will always evaluate to false and all token exchanges will be denied regardless of the correct repository or ref
Service account impersonation requires the Workload Identity User role on the service account; granting it at the project level instead of the service account level gives the workload identity pool the ability to impersonate any service account in the project, which is a privilege escalation risk
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp