Vault Secret Store
Initialise, unseal, and bootstrap the bundled HashiCorp Vault used to store API credentials.
The BoltMCP chart deploys a bundled HashiCorp Vault backed by the shared PostgreSQL (schema boltmcp_vault). It serves as a secret store for things like sensitive upstream API credentials. It boots sealed and uninitialized, single-replica, and its data persists across restarts. It's never exposed outside the cluster.
One-time setup
After the chart is installed and the boltmcp-vault pod is Running:
Initialize Vault - this generates the unseal/recovery keys and the initial root token. Store them securely, they cannot be recovered.
kubectl exec -it -n boltmcp deploy/boltmcp-vault -- \
vault operator initUnseal Vault - repeat this command three times, pasting a distinct unseal key each time you're prompted, until sealed flips to false:
kubectl exec -it -n boltmcp deploy/boltmcp-vault -- \
vault operator unsealWith the default Shamir seal, every Vault pod restart re-seals it, so you must repeat this step after restarts. For production, configure auto-unseal.
Run the bootstrap - this gives BoltMCP services read/write access. Log in with the root (or a suitably privileged) token, then run the chart-mounted script:
kubectl exec -it -n boltmcp deploy/boltmcp-vault -- \
sh -c 'vault login <root-token> && sh /bootstrap/vault-bootstrap.sh'This is idempotent, and a one-time action per Vault data lifetime, so you don't need to re-run it on every helm upgrade.
What the bootstrap creates
The bootstrap script is rendered from your values, so its names match the chart. With defaults it:
- Enables the KV v2 secrets engine at
secret/. - Enables the Kubernetes auth method at
kubernetes/and points it at the in-cluster API server (Vault uses its own pod token forTokenReview). - Writes policies granting read/write under a specific path (and metadata).
- Writes roles binding each ServiceAccount + namespace + token audience to the policies.
About Kubernetes auth
The chart gives each consuming BoltMCP service a dedicated ServiceAccount and an audience-bound, auto-rotated projected token. At request time the service logs in to Vault's Kubernetes auth method with that token, receives a short-lived Vault token, and uses it to read/write secrets. Vault runs as its own ServiceAccount bound to system:auth-delegator so it can perform the TokenReview that validates the login.