Sops original author here. I haven't contributed to the project in a few years, but it's really cool to see that it continued to grow and gain traction outside of Mozilla. Thanks folks!
I've used Mozilla SOPS on many projects and I highly recommend it. I'm not quite sure why, but it just doesn't feel like it gets the recognition that it deserves, which is why I'm happy to see it here on HN.
SOPS is the best git-friendly secrets management solution I've used.
It's also super easy to integrate into anything (provided you use go).
Shameless plug: I wrote a simple Kustomize plugin for it https://github.com/omninonsense/kustomize-sopsgenerator you can look at the code how easy it is to integrate as a Kustomize generator plug-in. It's just a few lines of code. I've not maintained it for a while now though
SOPS is really flexible and easy to work with once you get the hang of it. I haven't found any other good, vendor-neutral tools in the space.
Seems like the obvious way to go for storing secrets for 'GitOps' and IaC in general. I like the way it lets you combine GPG + Amazon KMS + instance IAM roles to sorta help ensure that secrets can only be accessed on some boxes.
I also like that it's not particularly Kubernetes-centric, so it's perfectly natural to use in simple ways in scenarios where Kubernetes would be major overkill.
Big fan of sops after previously using transcrypt. The latter was really painful for git newbies, painful to upgrade, and we've even ran into issues with differing versions of openssl on client machines.
sops is more contstrained but is generally easier to grok. It also integrates with GCP KMS which is super nice for us.
GPG is a footgun factory if you use it slightly carelessly, it doesn't usually fail safely (just today, I had it ignore `default-key` because it thought it was unusable, and randomly pick another) and it has too many options. That's kind of consensus. The author of age finds even stronger words[1].
Age is very limited in scope and it's not just a random person making a cryptography tool. That's pretty good in my book.
Can you mention some of these footguns? I don’t encounter footguns.
Once you set up the config and write your scripts, you are good to go! Its functionality and key management are very useful. OpenPGP is also battle tested, well supported.
But yeah it has too many options, and you need to know what options do, and set it up correctly.
Well, I already mentioned one, implicit choices. The "opsec safe" way to work around this is usually to just use a different --homedir. Another big issue I have is how easy it is to make assumptions as a user that aren't neccessarily true. Like that an encrypted message is usually signed, and that it isn't trivial to strip off signatures from encrypted payloads. I would absolutely never assume journalists know the threat model of GPG, which properties what message has, the potholes to avoid... I'd wager that even veteran users would occasionally fall for one of the many usability issues. And if it's just "sorry I lost my key".
I consider UX issues crucial to a security product, when fucking up can have severe consequences depending on what you do with GPG.
There are some use cases where pass and SOPS could reasonably be considered competitors, but for the most part, pass is best suited to personal/user secrets and SOPS is focused on infrastructure-as-code (e.g., secrets in Kubernetes or Nix configurations). There are no browser plugins for SOPS like there are for pass, for example. And SOPS has integration with more deployment tools than pass does.
Like pass, SOPS wraps the CLIs of local encryption/decryption tools such as GPG and age. Unlike pass, it also wraps the CLIs of cloud-based secrets management services.
One thing that potentially makes SOPS nicer for teams than pass is that you can freely mix and match the supported encryption and secrets management tools used to manage the secrets in a single project. So if we're on the same DevOps team and you prefer age but I need GnuPG in order to work with my PGP smartcard, we can still both easily manage and access the same secrets in the same repo together. Similarly, if we're working across teams, perhaps in a large organization or between two different organizations), we can use a single repo as a shared source of truth for shared secrets— even if one team is deploying their application to AWS and so it relies on Amazon's KMS for secrets, but the other team is deploying its application to Microsoft Azure and relies on Azure Vault for accessing secrets.
SOPS works with two layers of keys: it encrypts for various keys that, in some user-specified combination, can be used to decrypt the keys that can decrypt the user's actual in-repo secrets. SOPS supports using GPG, age, AWS KMS, Azure Vault, etc., for that outer layer (which is all the end user really has to think about).
re: GitHub Actions, GitLab CI/CD, etc.: SOPS is an alternative to entering your secrets in some web interface associated with your git forge or CI/CD service, so that your source code repository can be a single source of truth for all of the information needed to run your application, including any relevant secrets. In that way, your deployments no longer depend implicitly on the state of applications that offer to store secrets for you: those dependencies are made explicit, and those services are simply used to access part of your version-controlled source of truth about application deployment/configuration.
(If you want to use SOPS for secrets that you also need to access in your GitHub Actions or GitLab CI/CD, you can do so by making the `sops` CLI available in the environment of a self-hosted GitHub Actions Runner or GitLab Runner.)
