Looking at some of these encryption-as-a-service providers, I'm a bit confused on one of the selling points. From my limited understanding: with a traditional system, you encrypt in the database but your encryption key likely exists on your main server, possibly in an environment variable. Attacker compromises main system and has access to both encrypted data and encryption keys. So, you instead use something like Vault to request an encryption key in real-time from a remote service and thus don't need to store it on your server. So, one of their selling points on their site is that Vault is better because two systems would have to be compromised by an attacker in order to decrypt sensitive data. The part I don't understand though is, if an attacker has compromised my server, could they not just initiate a request to Vault for a decryption key at that point? I feel like I'm missing something because this sounds like it remains a single point of failure.
Vault looks great, but I always balk at the operational overhead. Also the cost is significant. I'm at a tiny org, though.<p>For smaller orgs and projects, Mozilla Sops is really great:<p><a href="https://github.com/mozilla/sops" rel="nofollow">https://github.com/mozilla/sops</a><p>It encrypts your secrets at rest using Google KMS, Amazon KMS, and various other cloud provider key services. You can then put those secrets into your code repository, cloud file storage, etc. and give your build pipeline a service account with the ability to decrypt the secret files.<p>Scales like crap, but is quick and dirty when you need it.
Congrats on the big milestone.<p>I’ve been extremely happy working with HashiCorp tools for the past several years.<p>Vault provides sooooo much out of the box, it’s hard for me to imagine spinning up a new project without it anymore. Which leads to my biggest fear...my jaded-self is expecting an ‘unfriendly’ acquisition (Microsoft, Alphabet) and/or some onerous licensing/pricing changes.
My understanding of vault is not ironclad, but from what I have read it seems it allows ephemeral passwords that allow your application to get access to a service at time of initialization, and then the password ceases to be valid. Which means your application has access, but there's no credentials floating around anywhere that they could be compromised later.<p>If anyone could correct me if I'm wrong, that would be great.
Confidant is another open-source product in this space <a href="https://lyft.github.io/confidant/" rel="nofollow">https://lyft.github.io/confidant/</a><p>Disclosure: I work at Lyft.
I spent a few months of side work time working on a "secure-deployment-seed" project, <a href="https://github.com/jteppinette/secure-deployment-seed" rel="nofollow">https://github.com/jteppinette/secure-deployment-seed</a>. It is a set of Ansible playbooks/roles that have Vault/Consul at the center of a standard web deployment where privacy/security is taken to the Nth degree of perfectionist driven insanity.<p>I ended up never using it, because it never really felt "perfect" to me.. There are so many circular dependencies between systems (DNS/Consul-Template/Consul/Vault/Ansible) and bootstrapping is just complete hell. Dive into that repo and witness it for yourself.<p>I can see myself using this setup if I was ever just doing Ops work, but when you are also doing everything else, it is just too much.<p>Anyways, congrats to the Hashicorp team. Your stuff really is topnotch.
We use <a href="https://square.github.io/keywhiz/" rel="nofollow">https://square.github.io/keywhiz/</a>. It provide secrets as files in a directory, securely. So no special API, client libraries required to access it.