CI credentials and OIDC trust conditions

Mechanism

CI systems often exchange an OIDC token for cloud credentials. The cloud trust policy must constrain token issuer, audience, and subject claims to the intended repository, branch, environment, or workflow context. A correct signature on a token from a legitimate CI issuer does not mean every job from that issuer should be trusted.

Practical method

Identify the issuing platform and cloud federation configuration. Map trust conditions to actual job claims and inspect how pull-request and environment contexts differ. Review credential lifetime and downstream role permissions. Test only with a dedicated lab job and redact tokens from logs.

CI issuer -> signed claims -> cloud trust conditions -> short-lived role
                           repository/environment scope belongs here

Interpreting evidence

A useful finding identifies an unintended job context satisfying the trust policy. Broad audience matching alone is not sufficient if subject restrictions correctly enforce the intended boundary.

Pitfalls and limits

Untrusted code can run before credential issuance. Reusable workflows alter claim context. Long-lived fallback keys can defeat the benefit of short-lived federation.