This is the first time I've seen a nicely documented requirements.txt and I like! <a href="https://github.com/lyft/confidant/blob/master/requirements.txt" rel="nofollow">https://github.com/lyft/confidant/blob/master/requirements.t...</a>
An alternative approach, if you don't want to be 100% tied to KMS, is <a href="https://github.com/mozilla/sops" rel="nofollow">https://github.com/mozilla/sops</a> . It uses KMS, but also PGP, and potentially anything that comes up in the future.
That's very nice. If you're using Microsoft Azure though, you might as well use Azure Key Vault[0].<p>[0] <a href="https://azure.microsoft.com/en-us/services/key-vault/" rel="nofollow">https://azure.microsoft.com/en-us/services/key-vault/</a>
How does this compare to Vault? [1]<p>Looks like Confidant is tied to AWS whereas Vault can use various backends..?<p>[1] <a href="https://www.vaultproject.io/" rel="nofollow">https://www.vaultproject.io/</a>
I'd love for someone to explain what you get from using a secret management service other than encrypted at rest blobs.<p>Ex. You store your AWS Master key in a config file, and you have Microservice A that reads that key from the file. Microservice A is compromised (or its VM is compromised). How does having a secret store help you here? Couldn't the attacker just inspect the code of Microservice A and see that you are just reading from disk/reading from Vault?<p>In short, what do services like this protect from me (other than accidentally checking in my code to a public repo?)
I have a genuine question, why not use S3 alone for secret management?<p>One selling point of Confidant is using IAM roles to bootstrap authentication to the secret store. You can also do that with S3, put each secret into an individual text file and give each IAM role permission to access the secrets it needs. Set the S3 bucket to encrypt the data at rest, it uses KMS behind the scenes and automatically rotates encryption keys.<p>Rotation of the secrets themselves could be scripted or manual, that part would be basically the same process as using Confidant or any other tool. And I believe S3 access can even be auditable with CloudWatch logs.<p>Also, S3 now offers either eventually consistent or read-after-write consistency. EDIT: actually, it looks like new object PUTS can be read-after-write consistent but updates are not. So this could be a downside, if you rotate a key getting the new one is eventually consistent. In practice this might not be a big deal though, there's already going to be a gap between when you activate the new key and when your app gets reconfigured to start using the new key.<p>I'm very curious what the downsides might be of doing this. For all the various secret management tools that have been released in the past year or two, I'm kind of surprised I've never heard anyone talk about using raw S3.
So they basically reinvented this?<p><a href="https://github.com/codahale/sneaker" rel="nofollow">https://github.com/codahale/sneaker</a>
Another alternative developed for AWS deployments, written in Python and uses KMS: Credstash
<a href="https://github.com/fugue/credstash" rel="nofollow">https://github.com/fugue/credstash</a>
Please correct me if I am wrong, but I think there is no secure way to store stuff in an virtual environment.<p>I wish I am wrong - cause my heart always bleeds if I see db passwords in configuration files! But As long as there is a hypervisor you do not control access to - you must trust the owner of the bare metal to (1) honor your privacy (2) be competent to secure his system. Trust is nice, but it is not security.<p>granted - Confidant and KMS seem better solution than most. Will look into it at more detail. thx for open sourcing it and moving the solution forward.
Nice way for Lyft to fire back after that iOS reverse-engineering video [1] revealed that they were showing off one of their keys in a production client. I don't know if this was intentional, and I believe whatever exploit they had was mild, but it restores (at first glance) my faith in them a bit :).<p>[1]: <a href="https://realm.io/news/conrad-kramer-reverse-engineering-ios-apps-lyft/" rel="nofollow">https://realm.io/news/conrad-kramer-reverse-engineering-ios-...</a>
"KMS provides access to master encryption keys,... but doesn’t provide direct access to the master key itself, so it can’t be stolen."<p>Doesn't Amazon KMS have access to the master key? And therefore, it can be stolen from them?
It's unfortunate that this is tied to AWS, while the industry is moving towards a cloud agnostic approach to hosting.<p>That being said, it seems like an interesting project to keep an eye on.