No key was stolen, but now they are your GCP service account
Workload Identity Federation lets an external identity impersonate a GCP service account with no key. One over-broad trust condition lets the wrong identity in. Here is the keyless attack, and the fix.
Keyless is supposed to be safer than a long-lived service-account key. It is, right up until the trust condition is too broad.
What it is
Workload Identity Federation lets an external identity, such as a CI/CD pipeline presenting an OIDC token, impersonate a GCP service account with no exported key. The control is the provider’s attribute condition, which should pin trust to a specific subject, repository, or organization. When that condition is missing or too broad, any identity the provider will accept, for example any repository on the same CI/CD platform rather than only yours, can exchange its token for your service account’s credentials. This is T1199 (trusted relationship) with T1550 (use alternate authentication material).
Why it works
There is no key to rotate and little default alerting, so it is stealthier than a leaked credential, not safer. The trust boundary is a single attribute condition that is easy to set too wide.
How to detect it
Look for a Security Token Service exchange from an OIDC subject outside your intended repository or organization, then impersonation of the service account from an unusual origin, in the Cloud Audit Logs.
The fix that holds
Pin every provider’s attribute condition to the exact subject, repository, and organization. Least-privilege the service accounts that can be impersonated, audit all pools and providers for broad or missing conditions, and alert on token exchanges from unexpected subjects.
Practice it
We built a Workload Identity Federation abuse scenario in GraphLattice Range so teams learn why there is nothing to rotate, and how to pin the trust that actually contains it.