Prefer OpenID Connect (OIDC) over stored cloud keys. With OIDC your pipeline requests a short-lived access token from the cloud provider for each job, so there is no long-lived credential sitting in your CI secrets to leak, rotate or duplicate.
The two approaches
With stored keys, you create a credential in your cloud account and copy it into your CI system as a secret. Every workflow run presents that secret. GitHub's documentation describes exactly this pattern and its downside: you create the credential in the cloud provider and then duplicate it in GitHub as a secret.
With OIDC, you set up a trust relationship once. The cloud provider then issues a short-lived token to a workflow that proves its identity. The GitHub guide says the token is valid for a single job and then expires automatically.
| Question | Stored cloud keys | OIDC |
|---|---|---|
| Is a long-lived secret kept in CI? | Yes | No |
| Who rotates it? | You, by hand or script | Nothing to rotate, tokens expire |
| Where is access scoped? | Often broad, per key | In the cloud provider's own policies |
| What if the repo secrets leak? | Key is usable from anywhere until revoked | No reusable key was stored |
What GitHub lists as the benefits
The GitHub documentation names three:
- No cloud secrets. You do not copy cloud credentials into long-lived CI secrets.
- Better authentication and authorization management. You use the cloud provider's own tools to decide how workflows may use credentials.
- Rotating credentials. The provider issues short-lived tokens that expire after the job.
Those line up with the OWASP secrets guidance, which prefers dynamic, short-lived secrets over long-lived reuse and says to automate rather than hand maintain.
Why it matters for payments
Pipelines for payment services usually have rights that matter: they can deploy code that moves money or reads sensitive tables. A leaked long-lived deploy key is an attractive target. OWASP's secrets cheat sheet also warns that attackers use CI/CD tooling to pull secrets out, which is a reason not to keep powerful ones there at all.
A short-lived token also helps your review story. Instead of explaining who has the deploy key, you can explain which workflow, on which branch, may assume which role.
Setup outline
- Create the trust relationship between your CI provider and your cloud account, following the provider's instructions.
- Create a role per environment with the minimum permissions to deploy there.
- Restrict the trust to specific repositories and branches or environments, not to your whole organization.
- Update the workflow to request a token and remove the stored key.
- Delete the old key in the cloud account, not just in CI.
Step 5 is the one people skip. A key that is no longer used but still valid is still a risk.
Limits to remember
OIDC is not a cure for a compromised workflow. If an attacker can change the workflow file on a branch that is allowed to deploy, they can request the same token. Pair OIDC with required reviews on workflow changes and deployment environment rules, covered in our other posts on pull request and environment controls.
Where Safeguard fits
Safeguard does not replace your CI identity setup. Its policies and gates can run at the pull request stage, and its agent identity feature helps track automated actors. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click a failing gate and note what a reviewer sees before a change reaches a deploy workflow.
Quick check
Does OIDC remove the need for any secret?
It removes the long-lived cloud credential from CI. You may still have other secrets, such as third party API keys, that need normal handling.
What should I scope the trust to?
Specific repositories and branches or environments, so a stray fork or branch cannot request a production token.
Sources
Last reviewed: 19 October 2026.
