Our secrets have accumulated in several places over the past year: a few repositories, .env files, Jenkins credentials, and developers' laptops. I want to fix this before it turns into an incident, but I also can't spend six months building an entire secrets platform.
The target state is runtime injection, with sensitive values removed from source control and CI configuration. Our IT team already operates Passwork for human credentials, and it provides an API and CLI, so we could potentially use it for machine secrets too. The alternative is adopting a dedicated secrets manager or the equivalent service from our cloud provider.
The main identity decision is whether to use OIDC federation so runners authenticate without long-lived credentials, or use a tightly scoped bootstrap secret and reduce its blast radius. What migration order and tooling would provide the best security improvement without requiring a massive rewrite?
4 Answers
Use OIDC federation first wherever your CI provider and cloud support it. The runner can receive a short-lived identity and assume a narrowly scoped role, so there are no permanent cloud access keys sitting in the pipeline. After that, the actual storage choice becomes less risky; a cloud parameter store or secrets manager is enough for many teams and doesn’t require operating a full Vault installation.
If you already have a cloud provider, its secrets service is usually the lowest-friction option. Store the values centrally, grant each workload only the paths or parameters it needs, and inject them during deployment or startup. A simpler secure-parameter store may be sufficient if you don’t need features such as automated rotation; a full dedicated system is not automatically better.
Start by stopping the bleeding: inventory and rotate anything that has been committed or shared broadly, and scrub repository history where necessary. A key exposed in an old commit should be treated as compromised. Then choose one managed secrets store as the source of truth and migrate pipelines incrementally instead of trying to move every .env file in one project.
That ordering has worked well for me too. Start new deployments with runtime injection, then migrate the older pipelines one at a time and retire the duplicate copies.
A dedicated manager such as Vault or OpenBao can work when you need detailed RBAC, dynamic credentials, or support across multiple environments and providers. Reusing Passwork might be reasonable for a short-term bridge, but verify that its machine-secret access, auditing, rotation, and workload identity features are strong enough before making it the long-term platform. Whichever store you choose, make it the source of truth rather than having developers edit CI credentials and then copying them into another system.
I’d strongly prefer OIDC over a supposedly temporary bootstrap credential. Temporary credentials have a habit of becoming permanent once the pipeline works.