Live data from Hacker News

Confidant: an open-source secret management service

eng.lyft.com

11–20 of 71 posts

Re: Confidant: an open-source secret management service

#11
post #5

"KMS provides access to master encryption keys,... but doesn’t provide direct access to the master key itself, so it can’t be stolen." Doesn't Amazon KMS have access to the master key? And therefore, it can be stolen from them?

https://aws.amazon.com/kms/faqs/ "AWS KMS is designed so that no one has access to your master keys."

"...never storing plaintext master keys on disk, not persisting them in memory, and limiting which systems can connect to the device..."

Translation: We promise to not look at your keys.

Granted, this is most likely better than nothing, especially if you trust AWS, but ideally, you want only the client to have the key material.

Re: Confidant: an open-source secret management service

#12

How does this compare to Vault? [1] Looks like Confidant is tied to AWS whereas Vault can use various backends..? [1] https://www.vaultproject.io/

FAQ in the post discussed this:

"The main difference between Confidant and the others is that Confidant is purposely not cloud agnostic, choosing to use AWS’s features to deliver a more integrated experience. By leveraging AWS’s KMS service, Confidant is able to ensure the master encryption key can’t be stolen, that authentication credentials for Confidant don’t need to be distributed to clients, and that authentication credentials for Confidant clients don’t need to generated and trusted through quasi-trustable metadata."

Confidant is purposely tied to AWS so that it can rely on KMS for its master key and for authentication.

Re: Confidant: an open-source secret management service

#13

Earlier quoted context omitted.

https://aws.amazon.com/kms/faqs/ "AWS KMS is designed so that no one has access to your master keys."

"...never storing plaintext master keys on disk, not persisting them in memory, and limiting which systems can connect to the device..." Translation: We promise to not look at your keys. Granted, this is most likely better than nothing, especially if you trust AWS, but ideally, you want only the client to have the key material.

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.

Re: Confidant: an open-source secret management service

#14

How does this compare to Vault? [1] Looks like Confidant is tied to AWS whereas Vault can use various backends..? [1] https://www.vaultproject.io/

FAQ in the post discussed this: "The main difference between Confidant and the others is that Confidant is purposely not cloud agnostic, choosing to use AWS’s features to deliver a more integrated experience. By leveraging AWS’s KMS service, Confidant is able to ensure the master encryption key can’t be stolen, that authentication credentials for Confidant don’t need to be distributed to clients, and that authenticat…

Indeed, thanks. I just found a little more on Vault's take on this: https://www.vaultproject.io/intro/vs/kms.html

Re: Confidant: an open-source secret management service

#15

How 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 Hashicorp ecosystem (Consul, weirdo HCL configs, etc) which is a plus or minus depending upon your perspective I guess. Vault servers are also stateful, which complicates deployment (you can't just stick N Vault servers behind a load balancer).

If I had infinite time I'd consider creating a "SimpleVault" fork consisting of exactly one secret and storage backend, one way to auth, one curated workflow and make it run in a stateless manner. I'd probably also remove all the clever secret generation stuff, since 90% of applications just require a secure place to store secret blobs of data, as opposed to creating dynamic time-limited IAM credentials on the fly or whatever.

Re: Confidant: an open-source secret management service

#16
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 :).

[1]: https://realm.io/news/conrad-kramer-reverse-engineering-ios-...

Re: Confidant: an open-source secret management service

#18

Earlier quoted context omitted.

"...never storing plaintext master keys on disk, not persisting them in memory, and limiting which systems can connect to the device..." Translation: We promise to not look at your keys. Granted, this is most likely better than nothing, especially if you trust AWS, but ideally, you want only the client to have the key material.

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

Re: Confidant: an open-source secret management service

#20
post #15

How 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…

Your fork description is pretty close to what Confidant is. You should give it a try if you're in AWS!
Post reply on HN