GitHub Actions Repository Secrets Without Expiration Enforcement

Direct Answers

• Can Actions detect an expired cloud credential before the provider rejects it? No. Secrets are opaque strings at runtime; there is no pre-flight validation or expiry hook.
• Is there a native setting to enforce secret expiration or rotation? No. Repository, environment, and organization secrets have no TTL field in the UI or REST API. Environment protection rules only gate access via reviewers — they do not set a credential lifetime.
• Should static-key workflows move to OIDC before the long-lived secrets are removed? Yes. Migrate to OpenID Connect federation first, then delete the static secrets. OIDC issues short-lived tokens per job, eliminating the need to store long-lived cloud keys.

Confirmed Facts

• GitHub Actions does not display or enforce an expiration date for any user-created secret (repository, environment, or organization level).
• The GITHUB_TOKEN is short-lived and expires when the workflow job finishes, but it does not govern user-created secrets.
• Long-lived static cloud keys stored as secrets remain valid until manually rotated or deleted.

Likely Explanation

The runner treats secrets as opaque strings. No built-in mechanism exists to inspect a cloud provider's credential metadata (expiry, rotation status) before the workflow step calls the provider's API. Failure occurs at the provider call, not at secret retrieval.

Recommended Steps

1. Inventory secrets — List every repository, environment, and organization secret that holds a static cloud credential (AWS access keys, Azure service principal secrets, GCP service account keys, etc.).
2. Enable OIDC federation for each cloud provider:
   • AWS: Configure an IAM OIDC provider and role with sts:AssumeRoleWithWebIdentity trusted on token.actions.githubusercontent.com.
   • Azure: Create a federated identity credential on the app registration pointing to the GitHub repo/org.
   • GCP: Enable Workload Identity Federation and map the GitHub OIDC token to a service account.
3. Update workflows to request OIDC tokens (id-token: write permission) and use the provider's official login action (e.g., aws-actions/configure-aws-credentials, azure/login, google-github-actions/auth).
4. Validate that all workflows succeed with OIDC tokens in a test branch.
5. Delete the static secrets once no workflow references them.

If You Cannot Migrate to OIDC Immediately

Build external rotation:

• Schedule a workflow (e.g., weekly) that calls the cloud provider's API to rotate the key, then updates the GitHub secret via the REST API (PUT /repos/{owner}/{repo}/actions/secrets/{secret_name}) using a GITHUB_TOKEN or PAT with repo scope.
• Or enforce a policy window: delete secrets after N days and require re-creation via a controlled process.
• Use a dual-secret strategy during rotation (keep SECRET_V1 and SECRET_V2) to avoid breaking in-flight runs.

One Diagnostic Detail

Which cloud provider(s) are the static credentials for? The OIDC migration steps differ per provider, and some (e.g., AWS) support condition keys to restrict the token to specific repos/branches, which affects the trust policy you write.