undefined | Better HN

0 pointsComputerGuru1y ago0 comments

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.

0 comments

curiousdeadcat1y ago

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.

j / k navigate · click thread line to collapse