Secrets are spread across repositories, CI credentials, .env files, and developer laptops. We want to move toward runtime injection without building a whole platform first.
We already have Passwork for human credentials. Should we use that for machine secrets too, or pick a dedicated store? And is OIDC worth setting up instead of keeping a bootstrap secret?
If you already run in a cloud, start by looking at its managed secrets service. Azure Key Vault or AWS Secrets Manager can give your workloads a central place to fetch secrets without adding another platform to operate.
On AWS, also compare Secrets Manager with SecureString parameters in Systems Manager Parameter Store. Parameter Store may be cheaper if you don't need Secrets Manager features like automated rotation. Check the current pricing and limits for your usage before choosing.
OIDC is worth considering for the pipeline identity. It lets a supported runner exchange a short-lived identity token for access instead of storing a permanent cloud access key or a service principal secret in CI.
Keep the trust policy narrow. Limit which repository, branch, or deployment environment can assume the role where your provider supports those claims, and grant that role access only to the secrets the job needs. The application runtime needs its own identity and permissions too. Pipeline identity alone doesn't make application secrets available at runtime.
Mervick.8c:
That distinction helps. We need to separate secrets used by the deployment job from secrets the running service needs.
Passwork is a reasonable thing to evaluate since it's already there, but having an API and CLI doesn't automatically make it the right fit for workload secrets. Check how machine authentication, fine-grained permissions, auditing, availability, and rotation would work for your jobs and services.
If it needs a long-lived bootstrap token, that's not necessarily a deal breaker. Scope it tightly, protect it in the CI system, and have a rotation plan. You'll still have a secret to manage, so be clear about the tradeoff.
If you aren't committed to a cloud provider, Vault or OpenBao are options for a dedicated secrets system. They also introduce something to deploy and operate, so I'd compare that overhead with a managed service and your existing tool before making it the first step.
Don't try to move everything in one shot. Inventory the secrets and where they're used, then pick one service or pipeline as a pilot. Move its reads to the chosen store, verify deployment and runtime access, and remove the old copies once the replacement works.
Credentials that were hardcoded or copied around should be candidates for rotation, not just relocation. Keep track of dependencies before rotating so you don't break an unrelated job.
Answers are reviewed before publication.
n6~turnkey_835:
Fetching at runtime still needs an identity with permission to read the right secrets. The store itself doesn't solve that part.