FWIW, KMS can get expensive if you're (for example) using transparent S3 encryption. Once you enable that (which is actually of dubious security value anyway), every S3 operation involves a KMS operation, which can get surprisingly substantial pretty fast. (I'm not making any comment on Sops per se - just saying to be careful around KMS,and thus Sops, for high-volume requirements.)
> (which is actually of dubious security value anyway)
FYI the value isn't necessarily in stopping AWS from maliciously reading your data if they wanted to (though it does make that slightly more difficult too), it's knowing that your data can't be easily recovered by someone who has access to the physical hard drives it's stored on. A typical scenario would be someone who knows where old drives are disposed of once they leave the data center - presumably AWS takes measures to wipe/destroy such drives, but knowing that the underlying data is encrypted at rest is extra assurance. There's also value for people whose compliance requirements dictate data is encrypted at rest regardless of cost and whether it actually makes sense to do.
I've been using SOPS daily for more than a year (before the rewrite from python into golang) and it works pretty well. It supports GPG for onprem installs and KMS for AWS. Its main supported filetypes are YAML and JSON files but I've used it with pretty much everything. The main benefit I've seen over other solutions is the ability to check my secrets into git knowing that they are encrypted. This means you can version your secrets while knowing that if your repo accidentally becomes public you won't suddenly end up with compromised servers. Usually for auth hosted services you still have to problem of how do you get the secrets into there in the first place through 100% automation.
We have been using Sops for a few months, it's pretty impressive really.
reading your Sops config during githooks allows you to ensure everything is encrypted before commit.
The only downside I have come across is that if you accidentally encrypt a file twice you essentially lose the data. obviously, this is user error but some additional protections around this would be good.
We've been using sops for about a year and it's a great solution to the startup problem of having secrets but needing to store them somewhere. The other options all involve additional infrastructure, while this just uses AWS infrastructure at the free level.
For a 1Password-like hosted service that also requires no additional infrastructure, check out EnvKey - https://www.envkey.com
It handles encryption keys completely behind the scenes, is trivial to integrate, and provides a UI to easily manage multiple environments and access levels in one place.
There will, of course, always be a role for more DIY solutions like sops, but if your goal is to have configuration/secrets secure, organized, and available to developers and servers in as little time as possible, you may find EnvKey interesting.
had the same issues and now i always either check for the sops encryption keys with a sops wrapper script before encryption or decrypt to a git-ignored temp file that is immediately deleted after use.
Very cool! It would be helpful to have a bit more description around how this works, especially for technical folks (like me) who have a working knowledge of encryption techniques, but lack deep knowledge in the field. I often think that half of the battle with security practice adoption is education- the easier something is to understand, the less friction to implement.
If you care about this, you can use Shamir Secret Sharing to require two (or more) keys to recover the encrypted file. So even if AWS was malicious, they still wouldn't be able to get the file without your other key (presumably a GPG or GCP KMS key)
