GitHub Actions to cloud without stored secrets: OIDC federation

Not specified by the original author.

TL;DR

Delete the static cloud secrets this replaces. 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. 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.

When to use

You are seeing this: GitHub acts as an OIDC identity provider for your workflows. Use this skill when you run into "GitHub Actions to cloud without stored secrets: OIDC federation".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

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

1. In the workflow job, set permissions: contents read, plus write on the token-request scope (the id-token key in the permissions block). Without that, GitHub will not mint the identity token for the run.
2. 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.
3. In the workflow, call the cloud's login action with the role to assume. No static credentials in secrets at all.
4. 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.

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.

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