[domenkozar]

I'm not advocating that different locations of secrets IS something we want, but rather it IS the sad state of reality.

By having a secrets specification we can start working towards a future that will consolidate these providers and allow teams to centralize it if needed, by having simple means of migrating from a mess into a central system.

[no_circuit]

I'm assuming that the PaaS/IaaS providers already have solutions for secrets. So a new centralized system may help with just dev and DIY bare metal?

But the centralized method, as in secretspec, not everyone will accept reading secrets in environment variables, as is also done with the 1password cli run command [1]. They also may need to be injected as files or less secure command line parameters. In the Kubernetes world one solution the is External Secrets Operator [2]. Secrets may also be pulled from an API as well from the cloud host. I won't comment on how that works in k8s.

To note, the reason for reading from file handles is so that the app can watch for changes and reload, e.g., key/token rotations without restarting the server.

But what could be useful to some developers is a secretspec inject subcommand (the universal version of the op inject command). I use op inject / dotenvy with Rust apps -- pretty easy to manage and share credentials. Previously I had something similiar written in Rust that also handled things like base64 / percent-encoding transforms.

If you aren't tied to Rust, probably could just fork external-secrets and get all the provider code for free.

[1] https://developer.1password.com/docs/cli/reference/commands/...

[2] https://external-secrets.io

[sofixa]

> DIY bare metal

Even then you can run a central Vault/OpenBao/whatever deployment.