Standalone Astral + Vault

[suprjinx]

If we want to package Astral with an Astral-managed Vault instance, we probably need to ensure a production-grade vault install. Perhaps adapt the official Helm chart?

There are a a lot of complexities to the production Vault install -- unsealing tokens with quorum, mTLS certs from some other source, etc.

[suprjinx]

Need some info: how production-grade should the standalone / managed Vault be?

1. does it need to be HA cluster?
2. presume K8S? Could Astral Helm chart include Vault Helm chart?
3. if K8S, can we rely on cert-manager to configure mTLS for Astral and Vault? (This kind of requires another Vault instance or similar to pre-exist our managed Vault)
4. if not k8s/helm, we may need a "configure" step to generate certs before bringing up Astral and Vault.

[suprjinx]

With production-grade Vault, we'd still want to deploy opensource which may lack some features. Can we achieve HA, etc, with opensource edition (or OpenBao)?

[GeorgeJahad]

@suprjinx and I discussed this one last week. We think it can be left for after the initial release.

[cipherboy]

@suprjinx wrote:

Can we achieve HA, etc, with opensource edition (or OpenBao)?

OpenBao has HA but not yet horizontal scaling. It is on our roadmap though:

4. Allow HA standby nodes to service read-only (from a storage modification PoV) requests. (scalability)
   • Currently HA mode standby nodes forward all requests up to the active node, preventing horizontal scalability of OpenBao. Due to limitations in Raft (only the active node can perform storage writes), we can't immediately scale writes. Thus, start by bringing these nodes "online" (loading the mount table, plugins, &c) and allowing them to service read-only requests, returning ErrReadOnly on storage write operations to trigger automatic request forwarding.
   • @cipherboy is happy to collaborate or author the RFC design document for this if someone wants to tackle it.