Is Vault a Single Point of Failure?

[Mark Riggins]

Is Vault a Single Point of Failure?

I see a lot of features and capabilities that my clients at LetXpert will want to use (like Tokens storing secrets), but I'm getting some pushback on one key issue, and wanted to make sure that I understand the tradeoffs correctly.

Tokens -- For access to systems through tokens, is there any way for new instances of applications to obtain fresh tokens when the Vault server is unavailable or unreachable?

Is there any way to have a locally-running Vault that can refresh tokens, or issue new tokens for a limited time?  [Perhaps with a special token that gives it a temporary privilege to issue tokens]

Secrets -- Ditto for secrets that are used by their applications to login to third-party APIs from other companies.

In other words,  what happens when the Vault server cannot be reached?

Mark Riggins

PS: I'm new to Vault, so I thought I'd take advantage of my free newbie questions :)

[Clay Bowen]

"Vault" as a service could be considered a single point of failure.  But then so could "network", "active directory", etc.  Vault will run on a distributed backend, such as Consul, and if you set the service up appropriately (many systems in different regions, as a cluster) the chance that Vault won't be available is very low.

Thanks,

Clay

[Mitchell Hashimoto]

In addition to what Clay said: you should also run Vault with standbys in production.

With standbys in multiple AZs and a redundant physical storage backend (such as Consul), you can tune the server counts to a point where it is statistically unlikely to ever not be able to reach Vault completely. Availability is always a matter of statistics, and Vault is better architected than most to ensure availability.

Best,

Mitchell

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/b4863c97-048c-49e5-91d9-c4b4abdbea04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Riggins]

 Running in multiple AZ's and with standby's should push availability to an acceptable level.  (Probably well past the other parts of the stack) Other "solutions", such as Chef's encrypted data bags also have availability issues when it comes to launching new nodes; and I'm sure we're all aware of their other limitations.

Thank you for the quick replies

Mark