I got so excited, but it doesn't seem to support multiple keys and seems overly eager to encourage people to leave a valuable key lying around on disk.

So if a single dev machine is compromised, all of your prod secrets are exposed?

I wish this were closer to sops with support for gpg and or ssh keys. Because sops is a great idea locked in a questionable codebase.

Happy to discuss a proposal to add asymmetric key support to the project in the GitHub issue tracker. Although I'm not sure how the security changes with an asymmetric key, as either way the worst case scenario is the same?

Note that you don't have to leave the key "lying around" as you can secure it the same way you would an asymmetric key. And it certainly beats leaving the plaintext secrets themselves lying around in a .env file or similar.

EDIT:

I see you were saying "dev machine" exposes "prod secrets" but that's not the case. The protocol is designed so you would have secrets.json and secrets.prod.json, encrypted with different keys and (necessarily) managed separately but with the same tools and api. Dev machines being compromised compromises dev keys, not prod keys.

Read the last section in the README on GitHub for more on the dev/prod split.

Asymmetric keys mean you can you can have per-dev or per-team keys and allow one team to rotate them and resign them for all other consumers. I don't know how you'd do that with symmetric keys. This is an important feature of sops, imo.

It also means I can do things like seal them to a key that is stored in KeyVault and then allow the transparent retrieval of that key at runtime on Instances that have been given an identity with access.

This means that production secrets are sealed in place and only openable by effectively authenticated workloads.

And if you use sops-nix, this becomes a "setup once and never think about it ever again, ever" kind of operation.

There's also sops: https://github.com/getsops/sops

I've used it at two jobs now over about 5 years and have had zero issues.

Another commenter mentioned it, I'm looking at it now.

SecureStore was launched in 2017 (initial version was .NET only): https://neosmart.net/blog/securestore-a-net-secrets-manager/

I don’t get it. There’s a symmetric secrets.key that anyone could get hold of and use to overwrite secrets? No thanks.

And where do I keep the key? In a secret store?

You keep the key wherever you want to keep the key, just don't commit it and don't distribute it. Put it in on a YubiKey for your devs, upload it out-of-band securely to prod.

Whether it's a symmetric key or an asymmetric key, you have the same problem. Someone overriding your secrets is definitely not high on the list of concerns, and if they're committed to git then they can never be truly overwritten.