Managed secrets with OpenBao.
Built for the full secrets lifecycle.
From authentication and access control to dynamic credentials, monitoring and recovery — the technology supports secure secrets management throughout its lifecycle.
- Dynamic credentialsGenerated on demand and valid for a limited time.
- Centralized secrets managementCredentials, keys and application secrets managed with centralized control.
- AuthenticationCallers authenticated before access is granted.
- Access controlScoped policies for applications, teams and environments.
- BackupsVault state backed up automatically.
- RecoveryRecovery capabilities for restoring vault state when needed.
- MonitoringVault health and access continuously monitored.
- APISecrets and lifecycle operations accessible programmatically.
- CLILifecycle operations accessible from the command line.
Secrets when needed. Control throughout.
OpenBao provides the open-source technology for centrally managing secrets, authentication and access. Dynamic credentials can be generated when needed and expire automatically, reducing reliance on long-lived secrets.
Applications, users & services
Applications, workloads and users authenticate when access to a protected resource is needed.
OpenBao
Secrets, authentication methods and access policies are managed centrally, with isolation where required.
Dynamic credentials
Short-lived credentials are generated with defined permissions and limited lifetimes.
Protected resources
Applications and users access databases, infrastructure and other protected services using authorized credentials.
Expire / revoke
Credentials expire or can be revoked when access is no longer required.
The open-source technology behind the secret management offering.
Discuss your secrets and identity approach.
We can walk through vault isolation, dynamic credentials and the operating model with your security architects.
Answered by engineers.
Q1We still manage credentials manually or in config files. What risk are we carrying, and how fast can we move to managed secrets?+
The risk is concrete: credentials sprawl across files and environments, nothing rotates, and one leak has a large blast radius. Moving is faster than most expect — a typical path from signing to a running service is around two months, so the gap closes while it is still a live concern.
Q2HashiCorp changed Vault's licensing and is now inside a larger vendor. Does moving to OpenBao remove that roadmap and licensing risk, or introduce a new one?+
OpenBao is the open-source path: a community-governed fork of Vault, so no single vendor can change its licensing or roadmap at will. That is lower risk here, not higher. And the exit stays open — you can continue on vanilla OpenBao and lose only Kumorion's automation.
Q3What do dynamic, short-lived credentials mean in practice for our developers and our security posture?+
Instead of one long-lived password, a credential is created when it is requested and expires automatically — a database credential with a TTL, for example. A leaked secret is already dead. For your security posture that means a smaller blast radius and a much easier audit trail.
Q4Which secret engines are supported, and which do we use first?+
The technology supports the standard engines — key-value, database, PKI and certificates, transit encryption and cloud integrations. We recommend starting where the pain is most common, usually database credentials or certificates, and expanding from there. The first step is deliberately small.
Q5How do applications and services authenticate to the vault?+
Through the standard auth methods — AppRole, Kubernetes auth, JWT or OIDC — mapped to your environment. If you also run Kumorion Containers, Kubernetes auth makes the integration especially straightforward. Existing applications need minimal change.
Q6Can we spin up isolated vaults per project, department or customer in a multi-tenant setup, and how quickly?+
Yes. Isolated vaults can be provisioned per project, department or customer, each with its own access policies — quickly, through the API. For a service provider, a vault per customer is a product in itself, with noisy-neighbour and blast-radius concerns handled by design.
Q7How is credentials rotation automated, and what happens to a running application if a credential rotates mid-session?+
Rotation is automated by the technology — credentials are renewed and expired on schedule without manual work. Applications that follow the standard renewal pattern keep running through a rotation; we help you adopt that pattern so rotation never breaks a live service.
Q8How are encryption keys protected, and do you support auto-unseal and HSM integration?+
Yes — auto-unseal and HSM integration are supported for environments with strict cryptographic requirements. Keys stay in infrastructure you control, which gives your audit team a clear cryptographic control story.
Q9How do you provide high availability and replication so the vault is never a single point of failure?+
The vault is deployed as a highly available cluster with failover, so losing a node does not stop the service. A vault outage would stop every application that depends on it — that is exactly why reliability is the headline of how we operate it.
Q10How does audit logging work, and can we export it into our SIEM for compliance?+
Every access is recorded in an immutable audit log — who accessed which secret and when. The log can be exported into your SIEM, giving your auditors the compliance evidence they ask for and streamlining your own certification work.
Q11What is the blast radius if a vault is compromised, and how is least privilege actually enforced?+
Access is scoped by policy per application, team and environment, so a single compromise is contained to what that identity could reach. Short-lived credentials shrink the blast radius further by design — there is no standing password to reuse.
Q12How do we migrate our existing secrets — from files, environment variables or HashiCorp Vault — into the service?+
There is a defined path from each source: files and environment variables are imported into the vault, and for HashiCorp Vault users the move to OpenBao is a well-trodden path rather than a rebuild. Application disruption is kept minimal throughout.
Q13How does managed secrets help us pass certifications our customers ask for, such as ISO 27001 or SOC 2?+
The features map directly to certification requirements: audit logging, automated rotation and scoped access control are the evidence auditors look for. You get artifacts, not just claims — and ISO 27001 certification is underway on Kumorion's side as well.
Q14As a CSP, can we resell this under our own brand, and how do we price it?+
Yes. The service can be offered under your brand, in the style of your own vault service, with a vault per customer as the product. That turns a cost into a revenue line — you price it with your own margin on top.
Q15What does this cost against building and retaining our own secrets expertise, and what is included?+
Secrets expertise is scarce and high-stakes to hire. As a rule of thumb, the service costs roughly one senior developer equivalent — against recruiting, retaining and on-calling a specialist team yourself. The fee covers operation, rotation, upgrades, monitoring and support.