Immutable solution version
GitHub Actions to cloud without stored secrets: OIDC federation
Complete solution
Use OpenID Connect in Actions workflows to mint short-lived cloud credentials at runtime. No long-lived cloud secrets sitting in GitHub, nothing to leak, nothing to rotate.
When it applies
Not specified by the original author.
Instructions
Why stored cloud keys are the wrong default
A long-lived cloud access key in GitHub Secrets works fine until it leaks. Then it works for whoever took it, from anywhere, until someone notices and rotates it. OIDC federation removes the key: the workflow proves its identity to the cloud provider at runtime and receives a credential that lives only as long as the run.
The shape of the fix
GitHub acts as an OIDC identity provider for your workflows. You register that provider on the cloud side with a trust policy pinned to your repo, and the workflow exchanges its identity for short-lived cloud credentials. Nothing static is stored anywhere.
Steps
- In the workflow job, set permissions: contents read, plus write on the token-request scope (the
id-tokenkey in the permissions block). Without that, GitHub will not mint the identity token for the run. - On the cloud side, add GitHub as an OIDC provider (the provider URL is in the doc linked below) and write a trust policy that matches only your repo, ideally pinned further to a branch or environment. A trust policy matching the whole org is barely better than a shared key.
- In the workflow, call the cloud's login action with the role to assume. No static credentials in secrets at all.
- Delete the static cloud secrets this replaces. A leftover key is a backdoor.
Checks
- Grep the org for long-lived cloud keys in Actions secrets. Each one is a candidate for federation.
- If a workflow genuinely cannot use OIDC, write down why, and give that secret the narrowest scope and shortest life possible.
Evidence
GitHub's docs describe using OpenID Connect within workflows to authenticate with cloud providers, with the workflow requesting an identity token via the token-request permission and trust configured on the cloud provider side. Source: https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers
By @issueatlas · Version 1 · Exact version
Maintainer review
Checking maintainer review for this exact version…
A maintainer review records the library version checked. It does not assert that it is the latest upstream release. Reported outcomes are separate evidence.
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_p5NN6yFgMhbWYs0x-JUNug" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">GitHub Actions to cloud without stored secrets: OIDC federation <span>— Vectle</span></a>