Vault (OpenBao)
1. Overview
The Vault add-on deploys an instance of OpenBao, an open-source fork of HashiCorp Vault. OpenBao maintains compatibility with Vault APIs, providing a robust tool for managing secrets, protecting sensitive data, and controlling access to tokens, passwords, certificates, and encryption keys.
Use it when your product needs secure secrets management, dynamic credential injection in applications, or encryption as a service, using an open technology base.
Catalog tags: Security, Secrets, Vault, OpenBao.
2. Prerequisites
- A squad and an environment already selected on the Add-ons screen.
3. Deployment Step-by-Step
The Vault deployment wizard has 3 steps:
Step 1 — General
| Field | Required | Description |
|---|---|---|
| Add-on Name | Yes | Name of the add-on within the environment. Only lowercase letters, numbers, and hyphens. Example: my-vault. |
| Admin Public | No | When turned on, the Vault administrative panel is publicly accessible. Off by default (access restricted by the platform). |
Step 2 — Seal Type
Defines the instance's sealing and unsealing method.
| Field | Default | Options |
|---|---|---|
| Seal Type | Shamir | Shamir or GCP Cloud KMS |
Sealing Configuration (Seal Type)
The available methods are Shamir and GCP Cloud KMS:
- Shamir: the platform performs an automatic initial unseal, so the Vault is usable right after deployment. This option still allows seal/unseal operations to be performed manually later, by whoever administers the instance.
- GCP Cloud KMS: The entire seal/unseal flow is fully automated and managed by Google Cloud's KMS service. With this configuration, manual seal/unseal is not possible, and the entire master key lifecycle is delegated to the cloud provider.
Step 3 — Resources
Defines the computational resources allocated to the instance.
| Field | Default | Suggestion/Maximum |
|---|---|---|
| Memory Request | 256Mi | 512Mi |
| Memory Limit | 512Mi | 2Gi |
| CPU Request | 100m | 500m |
| CPU Limit | 500m | 2000m |
| Storage Size | 1Gi | 10Gi |
Clicking Deploy Add-on starts the deployment. The add-on will then appear in the environment's My Add-ons tab.
4. After Deployment
After deployment, the Vault is initialized automatically. When Seal Type is Shamir, the platform itself performs the initial unseal and manages the unseal keys — nothing has to be done manually to start using it.
Advanced Administration
The add-on provides advanced administration features through the platform or the add-on's native portal:
-
Secrets Engines: Through the platform's administrative panel, only the KV (Key-Value) engine is available for direct configuration. Other engines can be configured as needed through the OpenBao Vault native portal.
Engines available for use today are:
- Generic: KV (Key-Value), PKI Certificates, SSH, Transit, TOTP, Kubernetes.
- Infra: Databases, RabbitMQ.
-
Policies: Definition of granular access policies in HCL format.
-
Auth Methods: Configuration of authentication methods, including Tokens, Userpass (local users), and AppRole (identities for machines/services).
-
Secret Export: Exclusive feature that allows exporting a Vault credential (such as an AppRole) directly to a platform Secret, facilitating integration with other flows.
5. FAQ
How do I access my Vault keys (unseal keys, root token, etc.)?
The platform fully manages this sensitive information, and it is not made available to the user. Vault is provided in a fully managed model to ensure maximum security and simplify operation, eliminating the need for manual key custody by the user.
If my Vault instance is restarted or sealed for some reason, do I need to perform the unseal manually?
No manual intervention is necessary. The platform continuously monitors the instance's state and ensures automatic unsealing (auto-unseal) to allow for transparent and uninterrupted service usage.