When I first built a deployment pipeline, I put database passwords and API keys in GitHub Actions Secrets and assumed encryption made them safe. I'm now realizing that a secret can still be a static, long-lived credential: it may remain valid after a job completes, be difficult to audit, and stay usable if a workflow or runner is compromised. I'm considering a setup where the workflow authenticates using OIDC or another federated identity, retrieves short-lived credentials at runtime, and limits access based on the branch, pull request, or deployment environment. How are you handling this in practice? Do you rely on built-in CI/CD secret storage, or use a cloud secrets manager or Vault with temporary credentials and narrowly scoped permissions?
4 Answers
The biggest improvement is reducing blast radius. Give pull requests, staging, and production different identities and policies, and make sure an untrusted pull request cannot assume the production role or read production secrets. Protected branches and deployment environments should map to separate workload identities, with short token lifetimes and clear audit trails.
A common approach is to use the CI platform’s OIDC integration with a cloud provider. The workflow exchanges its identity for a short-lived role or token, then reads only the secrets it needs from a managed secrets service. That avoids storing long-lived cloud credentials in the CI system and gives you audit logs and automatic expiration.
The important distinction is that the trust configuration and IAM policy must be temporary and scoped too; moving a static credential into the secrets manager by itself doesn’t solve the problem.
For hybrid or multi-cloud setups, Vault works well. The runner authenticates to Vault with its JWT or OIDC identity instead of keeping a Vault client ID and secret, and Vault issues dynamic credentials or returns tightly scoped secrets. The CI platform should contain no application secrets, and access policies should be separated by environment.
For an AWS-only environment, the native secrets service may be simpler, but Vault can be worth the operational cost when portability and multiple providers matter.
You can also use a GitHub App or workload identity to mint tokens on demand. In Kubernetes, an external-secrets operator can retrieve values from a central secret store and distribute them to selected namespaces, while the underlying access tokens remain short-lived. It’s also worth questioning whether every value needs to be a secret at all—some deployments can use workload identity or configuration instead of credentials.
OIDC is supported by more than just one cloud provider, and you may not need a separate secrets-manager hop if the platform can issue the temporary identity directly.