5 ms·

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/ https://www

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/ https://www.vaultproject.io/

ryan_lane 11y ago
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.
- austinjp 11y ago
  Indeed, thanks. I just found a little more on Vault's take on this: https://www.vaultproject.io/intro/vs/kms.html https://www.vaultproject.io/intro/vs/kms.html
bkeroack 11y ago
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.
- ryan_lane 11y ago
  Your fork description is pretty close to what Confidant is. You should give it a try if you're in AWS!
- mitchellh 11y ago
  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 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).
  - pamad05 11y ago
    Hi, quick question since you seem to be on top of Vault. My team and I were investigating possible configuration options and secret management, and we couldn't figure out a good reason as to why the tool doesn't use S3 as one of the backends, which would essentially eliminate the need to maintain our own etcd/consul/sql whatever - plus, since the entire thing is path based, it seems incredibly well suited for that backend. I couldn't think of one, but I might be missing something.
    - deleted 11y ago
      [deleted]
    - jefferai 11y ago
      S3 is one of the available storage backends. You only need consul/etcd/zookeeper if you want to have a high availability setup.

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/ https://www.vaultproject.io/

ryan_lane 11y ago

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.

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

bkeroack 11y ago

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.

ryan_lane 11y ago
Your fork description is pretty close to what Confidant is. You should give it a try if you're in AWS!
mitchellh 11y ago
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 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).
- pamad05 11y ago
  Hi, quick question since you seem to be on top of Vault. My team and I were investigating possible configuration options and secret management, and we couldn't figure out a good reason as to why the tool doesn't use S3 as one of the backends, which would essentially eliminate the need to maintain our own etcd/consul/sql whatever - plus, since the entire thing is path based, it seems incredibly well suited for that backend. I couldn't think of one, but I might be missing something.
  - deleted 11y ago
    [deleted]
  - jefferai 11y ago
    S3 is one of the available storage backends. You only need consul/etcd/zookeeper if you want to have a high availability setup.