This is the first time I've seen a nicely documented requirements.txt and I like! https://github.com/lyft/confidant/blob/master/requirements.t...
Confidant: an open-source secret management service
21–30 of 71 posts
Re: Confidant: an open-source secret management service
#22So they basically reinvented this? https://github.com/codahale/sneaker
We wrote Confidant in the beginning of 2015, so it's not a reinvention of sneaker. That said, sneaker is very similar in design, as is credstash: https://github.com/fugue/credstash
Both of those are really great projects and I recommend them if they fit your use-case.
One of the reasons we originally avoided S3 was because it can occasionally be very eventually consistent, which we wanted to avoid. We also wanted to avoid fanning out secrets to services when the secret needed to be shared between multiple services.
We also wanted to have a UI that was simple and easy to use for everyone.
Re: Confidant: an open-source secret management service
#23Another alternative developed for AWS deployments, written in Python and uses KMS: Credstash
https://github.com/fugue/credstash
Re: Confidant: an open-source secret management service
#24This is the first time I've seen a nicely documented requirements.txt and I like! https://github.com/lyft/confidant/blob/master/requirements.t...
No more "pip freeze | sort -f > requirements.txt", explicit dependencies are way more maintainable!
Re: Confidant: an open-source secret management service
#25Another alternative developed for AWS deployments, written in Python and uses KMS: Credstash https://github.com/fugue/credstash
The only downside of credstash is that it doesn't have the ability to restrict sets of credentials to different IAM roles. The access is all-or-nothing, per dynamo table.
Otherwise the general design of credstash is very similar to Confidant.
Re: Confidant: an open-source secret management service
#26It's unfortunate that this is tied to AWS, while the industry is moving towards a cloud agnostic approach to hosting.
That being said, it seems like an interesting project to keep an eye on.
Re: Confidant: an open-source secret management service
#27It's unfortunate that this is tied to AWS, while the industry is moving towards a cloud agnostic approach to hosting. That being said, it seems like an interesting project to keep an eye on.
I'd say the opposite - the industry is in general being a lot more comfortable with investing in AWS to the point of lockin being acceptable now. More people are treating cloud providers less like a big pool of IP addresses.
Not saying it's a good or bad thing, but attend AWS reInvent or something and it's pretty easy to percieve huge uptake.
If you adopt extra management stacks running on or against your cloud you lose a lot of the benefits.
Re: Confidant: an open-source secret management service
#28How does this compare to Vault? [1] Looks like Confidant is tied to AWS whereas Vault can use various backends..? [1] https://www.vaultproject.io/
Vault is a nice piece of engineering (we use it), but it has what I call serious "backend-itis". Everything is pluggable, which makes it a bit of a nightmare to understand and use. For example, "secret backends" and "storage backends" are entirely separate things, but the docs aren't super clear about it (not to mention auth backends, audit backends, listeners ...). Unsurprisingly it buys completely into the Hashicor…
I just want to correct some of your points, I don't want to detract or compare Vault to Confidant here, as this is their time to shine!
"Buys into the HashiCorp ecosystem": Consul is completely optional. We also support ZooKeeper, SQL, etcd, and more. There is zero forced tie to Consul. HCL is correct though!
"you can't just stick N Vault servers behind an LB": Actually, that is exactly what we recommend! https://vaultproject.io/docs/concepts/ha.html Vault servers are stateful in that there can only be one leader, but we use leader election and all data is stored in the storage backends, so it can die without issue.
"90% of applications just require a secure place to store secret blobs": Just use Vault out of the box. You'll have to configure only storage, after that you can use the token you get from initialization (one form of auth) and the `/secret` path to store arbitrary blobs that is preconfigured (one form of backend).
Re: Confidant: an open-source secret management service
#29It's unfortunate that this is tied to AWS, while the industry is moving towards a cloud agnostic approach to hosting. That being said, it seems like an interesting project to keep an eye on.
I'm in agreement with mpdehaan2 here.
By sticking with a single cloud provider you get a lot of benefits. One of the more major benefits is cost, as you can do things like reserved instance in EC2. Another major benefit of sticking with a single provider is that you get to use solutions that only that provider has, which in this case is KMS, DynamoDB and IAM.
The biggest downside of being cloud agnostic is that you're stuck with the smallest combination of features that all of the clouds provide.
Re: Confidant: an open-source secret management service
#30Earlier quoted context omitted.
If you're running in AWS with any secret management service that isn't using CloudHSM, you're trusting AWS with your key material. There surely is some amount of trust there, though.
My undertanding was that the Customer Master Key was stored in an HSM, but your customer-generated keys were not. I might be wrong about that. So if true, AWS employees would not have access to your root key material, but the definitely the intermediary key material. It's a cost trade-off
Either way, you have to bootstrap secret material onto your instances somehow, so you've got to trust Amazon somewhere.
Not to diminish your point -- the how/where/when really does matter. Locking your house key in your car is still better than leaving it on your front step, but also not as good as in your pocket.