Using GCP Workload Identity Federation for keyless CI/CD ...

Every long-lived GCP service account key sitting in a GitHub Actions secret is a standing liability. It doesn't expire on its own, it can be copied out of a compromised runner in seconds, and once it leaks, an attacker has the same permissions your pipeline does until someone notices and rotates it. Google has spent the last few years steering customers away from downloadable service account keys entirely, and for good reason: leaked long-lived credentials remain one of the most common root causes of cloud breaches across every major provider. GCP Workload Identity Federation solves this by letting your CI/CD pipeline authenticate using a short-lived, cryptographically verified identity token instead of a static secret. No key file, no download, no rotation schedule to fall behind on. This post walks through what it is, why it matters for GitHub Actions and other CI systems, and how to roll it out without breaking your deploys.

What Is GCP Workload Identity Federation?

GCP Workload Identity Federation (WIF) is a Google Cloud feature that lets external identities — a GitHub Actions run, a GitLab pipeline, an AWS IAM role — exchange a short-lived, signed token for a temporary Google Cloud access token, without ever creating or storing a service account key. Instead of provisioning a service account, generating a JSON key, and pasting that key into a secrets manager, you configure a workload identity pool and provider that trusts tokens issued by an external identity provider (IdP). GitHub, for example, issues an OpenID Connect (OIDC) token to every workflow run, signed by GitHub's own OIDC issuer (token.actions.githubusercontent.com). WIF verifies that signature, checks the token's claims against attribute-mapping rules you define, and — if they match — hands back a Google Cloud access token scoped to whatever IAM role you've bound to that identity. The credential exists only for the duration of the token exchange and the short session that follows, typically capped at one hour. There is no long-lived secret anywhere in the chain.

This is what "keyless authentication GCP" actually means in practice: not that authentication disappears, but that the artifact an attacker would need to steal — a downloadable, indefinitely valid key — never exists in the first place.

Why Does GitHub Actions GCP OIDC Integration Matter So Much Right Now?

It matters because service account key leaks remain one of the most common, most preventable causes of cloud incidents, and GitHub Actions runners are a favorite target precisely because they routinely hold deployment credentials. A single secrets.GCP_SA_KEY pasted into a repo's Actions secrets is one misconfigured pull_request_target workflow, one compromised third-party Action, or one careless echo $SECRET in a debug step away from being exfiltrated. Once that key is out, it's valid until someone manually revokes it — which in practice can be days, weeks, or never, especially in organizations with dozens of repos and no centralized key inventory.

GitHub added native OIDC token support for Actions in 2021, specifically so workflows could authenticate to cloud providers without static secrets, and Google added first-class support for federating GitHub's OIDC tokens through Workload Identity Federation shortly after. Since then, adoption has accelerated across every major cloud: AWS offers the identical pattern through IAM roles for OIDC, and Azure through workload identity federation for federated credentials. The GitHub Actions GCP OIDC path is the reference example most engineering teams reach for first, because Google's own google-github-actions/auth action documents it directly, and the failure mode of getting it wrong — an overly broad attribute condition — is easy to lock down with a single attribute.repository == 'org/repo' check.

How Do You Actually Eliminate Service Account Keys in a Pipeline?

You eliminate service account keys by replacing the google-github-actions/auth step's key-based configuration with its workload_identity_provider and service_account parameters, which trigger the OIDC exchange automatically instead of reading a credentials file. Concretely, the migration looks like this:

1. Create a workload identity pool: gcloud iam workload-identity-pools create "github-pool" --location="global"
2. Create a provider inside it that trusts GitHub's OIDC issuer, mapping claims like assertion.repository and assertion.ref to Google attributes.
3. Add an attribute condition restricting the pool to your specific repository and, ideally, your default branch — for example, assertion.repository == 'safeguard-org/deploy-service'.
4. Grant the target service account the roles/iam.workloadIdentityUser role, scoped to the specific principalSet from your pool, rather than a broader role at the project level.
5. Update the workflow YAML to call google-github-actions/auth@v2 with workload_identity_provider and service_account inputs instead of credentials_json.
6. Delete the existing service account key with gcloud iam service-accounts keys delete, after confirming no other workflow still references it.

Most teams can migrate a single pipeline in under an hour. The larger effort is usually organizational: finding every repo that still has a GCP_SA_KEY secret checked in, migrating each one, and then disabling key creation at the org policy level with a constraint like iam.disableServiceAccountKeyCreation so nobody quietly reintroduces the old pattern six months later.

What Happens If the Attribute Conditions Are Too Loose?

If the attribute conditions on your workload identity pool provider are too permissive, any repository or branch in your GitHub org — or in some misconfigurations, any workflow that can forge a matching claim — can mint valid GCP credentials for your service account. This is the single most common WIF misconfiguration security teams find in practice. A provider configured with a condition like assertion.repository_owner == 'my-org' but no repository or branch restriction means a pull request from a fork, or a compromised low-privilege repo in the same org, can potentially exchange its OIDC token for access to a production service account. The fix is to scope conditions as tightly as the pipeline allows: pin to the exact repository, the exact ref (refs/heads/main), and, where possible, the specific workflow file path, so a token minted for a test workflow in a side project can't be replayed against a deployment role.

Does Workload Identity Federation Work Beyond GitHub Actions?

Yes — WIF is IdP-agnostic, and the same pattern works for GitLab CI, CircleCI, Bitbucket Pipelines, Terraform Cloud, Jenkins with an OIDC plugin, and even workloads running on other clouds like AWS or Azure that need to call GCP APIs. Any system capable of issuing a signed OIDC or SAML token can be federated, which is why GCP Workload Identity Federation has become the standard building block for keyless authentication GCP-wide, not just a GitHub-specific trick. Multi-cloud organizations frequently use it to let an AWS Lambda function or an Azure DevOps pipeline assume a GCP identity for a specific task — such as writing to a BigQuery dataset or triggering a Cloud Run deployment — without provisioning cross-cloud service account keys, which are historically even harder to track and rotate than in-cloud ones.

How Safeguard Helps

Migrating to GCP Workload Identity Federation removes one major class of standing credential risk, but it doesn't eliminate the need for visibility into everything else touching your CI/CD pipeline — the third-party Actions, the build scripts, the artifact registries, and the dozens of other secrets that still live alongside your cloud auth. Safeguard's software supply chain security platform continuously inventories every credential, workload identity binding, and third-party dependency referenced in your GitHub Actions, GitLab CI, and other pipeline configurations, flagging leftover service account keys, overly broad attribute conditions on workload identity pools, and secrets that should have been retired when a team migrated to OIDC but never got cleaned up.

Rather than relying on a one-time migration checklist, Safeguard treats CI/CD authentication hygiene as an ongoing signal: it detects when a new workflow introduces a static credential where a federated identity would do, surfaces workload identity pools with conditions broad enough to allow cross-repository token replay, and correlates pipeline permissions against the actual deployment scope a workflow needs — so a build job that only pushes container images isn't quietly holding project-owner-level access. For teams that have already done the work to eliminate service account keys, Safeguard provides the continuous verification that the keyless setup stays that way as pipelines, repos, and teams change.