# 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
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.