OIDC for CI: limit the identity your cloud trusts, not only token lifetime
Check issuer, audience and workload identity conditions before allowing a pipeline to obtain cloud authority.
In brief
OIDC can let a supported workflow obtain temporary cloud credentials instead of storing a long-lived secret. Google’s report highlights that token and pipeline abuse still matter: temporary does not mean harmless.
The useful configuration binds the cloud role to the intended repository, workflow or environment and only the required operations.
Match the intended workload
Define which repository and protected environment should qualify. Review the actual claim format and role trust conditions rather than a copied broad example. A token for one workflow should not automatically authorize every project belonging to the same organization.
Keep the role narrow
Temporary credentials can still delete resources or publish releases if the role permits it. Use the intended action and resource scope. Protect workflow changes and environment approvals so somebody cannot alter the supposedly trusted job to use that authority differently.
Validate and respond
Test an authorized request and a deliberately out-of-scope harmless case. Keep non-secret identity event records. If a pipeline was compromised, review trust and cloud activity; waiting for one token to expire does not fix the workflow that can mint another.
Before you act
Trust-policy syntax differs by provider. An overly broad federation policy can grant access to unintended workloads even with short-lived tokens.
What to do next
- Identify the issuing CI identity and cloud role accepting it.
- Check the required audience and workload claims through both providers’ current guidance.
- Limit resource permissions and test denial for an unintended branch or workflow before relying on the route.
