OpenBao vs Kubernetes Secrets: when each one is enough
Kubernetes Secrets are enough for a small cluster holding low-sensitivity values, provided encryption at rest and tight RBAC are already in place. An external secrets manager such as OpenBao becomes necessary when you need dynamic credentials, automatic revocation, central audit or one secrets service across several clusters. The starting fact to plan around is that Kubernetes Secrets are stored unencrypted in etcd by default, and anyone who can create a Pod in a namespace can read every Secret in that namespace. Before you decide anything, confirm whether your clusters already enable encryption at rest for Secrets and whether RBAC limits get, list and watch on Secrets to the people and service accounts that truly need them.
Kubernetes Secrets fit well when the values are static, few in number and used by one team in one cluster, such as a registry pull credential or a non-production API key. They also fit when your platform already controls etcd access, backs it up and restricts API access tightly, and when rotation is a manual, infrequent task. OpenBao fits when the workload needs short-lived database or cloud credentials generated on demand through its dynamic secrets engines, when leases must be revoked automatically or in bulk, when security wants a central audit trail across clusters, or when several teams need one policy model. Its Kubernetes auth method can also let workloads authenticate with their service account identity rather than a long-lived stored value.
The decision turns on three things: how sensitive the data is, how many clusters and teams will share it, and how much operating effort your team can carry for a secrets service. OpenBao adds a stateful system with its own unseal process, storage backend and high availability design, so ask who will own upgrades, backups and recovery before committing. Many teams keep Kubernetes Secrets for low-risk configuration and use OpenBao for credentials that need leases, while combining the two through the Kubernetes auth method and a delivery mechanism such as the Secrets Store CSI Driver. Confirm each step in your own environment before you rely on it.
Which scenario favors Kubernetes Secrets and which favors OpenBao
This table maps common team situations to the option that usually fits better, with the condition that makes each choice hold. Read each row against your own cluster count, audit obligations and appetite for running another stateful service, because the right answer changes when those conditions change.
| Scenario | Better fit | Why |
|---|---|---|
| A single cluster with a few static application values | Kubernetes Secrets, with encryption at rest enabled | Holds only if the values are low-sensitivity, rotation is infrequent and the team can enable encryption at rest and tight RBAC on the API server and etcd. |
| A multi-cluster platform sharing credentials | OpenBao | Kubernetes Secrets are scoped to one cluster's API and etcd, so a central store with policies gives one place to manage and revoke shared credentials across clusters. |
| Workloads needing short-lived database credentials | OpenBao | OpenBao's dynamic secrets and leases issue credentials per workload and revoke them automatically, which static Kubernetes Secrets do not do on their own. |
| A team with no appetite to run another stateful service | Kubernetes Secrets, possibly with a managed external store | OpenBao needs its own storage backend, high availability and unseal process to operate. If nobody will own those tasks, the operating cost outweighs the benefit. |
| A regulated environment where secret access must be audited | OpenBao, if audit logging is a hard requirement | OpenBao records requests against each secret path, while Kubernetes Secret reads are only visible through API audit logs that must be configured and retained. Confirm with your assessor which evidence they expect. |
| Pods that can create Deployments in a shared namespace | OpenBao, with per-workload policies | Anyone who can create a Pod in a namespace can read its Secrets, including indirectly through a Deployment. Central policies narrow access per workload instead of per namespace. |
| A team already using Kubernetes auth in a central store | Both, combined through the Kubernetes auth method | Workloads authenticate with their service account to OpenBao, so credentials are fetched at runtime rather than stored as cluster objects. This holds only if the team can operate OpenBao reliably. |
| Small teams that need secrets only for CI pipeline variables | Kubernetes Secrets or the existing CI secret store | The added value of OpenBao is small when no dynamic credentials, rotation or audit requirements exist. Confirm the pipeline's own secret handling first. |
How Kubernetes Secrets and OpenBao store and serve secrets
Both systems hand secrets to workloads, but they make very different promises about where the data sits and who runs it. The cards below follow one secret through each design, from storage and encryption to delivery into a Pod and high availability, so you can see which operating duties move to your team.
Where Kubernetes Secrets live
Kubernetes Secrets are stored in the API server's data store, etcd, and are unencrypted by default. Anyone with API access or direct etcd access can read or change them. Encryption at rest must be configured on the API server by your platform team. Check whether it is enabled in every cluster, and whether etcd snapshots taken for backup are protected with the same care as the live data.
How Pods consume Secrets
A Pod reads a Secret either as environment variables or as files in a mounted volume. Environment variables are easy to leak through logs, crash dumps and child processes, while mounted files can be refreshed in place. Anyone allowed to create a Pod in a namespace can read every Secret in that namespace, including indirectly through a Deployment, so RBAC scope matters as much as the delivery method.
How OpenBao encrypts data
OpenBao encrypts secret data before it is written to its storage backend, which can be integrated Raft storage or PostgreSQL. The storage layer therefore holds ciphertext rather than readable values. Your team owns the storage choice, backup and restore of that backend, and the unseal process that makes the encrypted data usable after a restart. Confirm your unseal method and recovery procedure before go-live.
How OpenBao runs in HA
In a high availability setup, one active node holds a lock in the data store, and standby nodes forward or redirect client requests to it. Integrated storage and PostgreSQL are the officially supported HA backends. Operationally, you must monitor the lock holder, size the standby nodes, and rehearse failover. Confirm with your own environment how the load balancer and client addresses behave during a leader change.
Operating the Kubernetes side
Because Secrets live in etcd, your Kubernetes operations include etcd backup and restore duties, using snapshot and restore tooling, and a backup plan that covers Secret data. Upgrades must respect the version skew policy. Teams that also run an external secrets store still need etcd protection for any Secrets they keep, so the backup scope should be written down explicitly.
Operating the OpenBao side
OpenBao adds its own duties: storage backend operations, backup of the encrypted store, the unseal procedure, and access policy for each client. Its leases and dynamic secrets can be revoked automatically or in bulk, which changes how incidents are handled. Ask your OpenBao operators to document who holds unseal material and how revocation is tested, since these steps decide recovery time after an incident.
OpenBao vs Kubernetes Secrets feature by feature
This table compares what native Kubernetes Secrets provide with what OpenBao adds, row by row. Read the Kubernetes column as the baseline and the OpenBao column as what an external secrets manager contributes, and check any cell marked as configuration-dependent in your own cluster before relying on it.
| Capability | Kubernetes Secrets | OpenBao |
|---|---|---|
| Default storage and encryption at rest | Stored unencrypted in etcd by default; encryption at rest must be configured by the cluster administrator | Key/value data is encrypted before it is written to the storage backend |
| Access control model | Kubernetes RBAC; least-privilege roles should restrict list and watch access to Secrets | OpenBao policies attached to tokens and identities returned by its auth methods |
| Exposure through Pod creation rights | Anyone allowed to create a Pod in a namespace can read any Secret in that namespace, including via a Deployment | Access depends on the policy bound to the identity; a Pod-creating user does not inherit secret reads by default |
| Dynamic secrets for databases and cloud systems | Not provided natively; typically handled by the application or an add-on | Dynamic secrets for systems such as Kubernetes and SQL databases; confirm the engines you need in your OpenBao version |
| Leasing and revocation | No lease model; rotation and revocation are manual or handled by external tooling | Leasing with automatic revocation and bulk revocation |
| Encryption as a service | Not provided | Encryption as a service is available; confirm the exact engine configuration you plan to use |
| Auth methods | Kubernetes authentication for workloads and users; OIDC and webhook options depend on the API server setup | Documents Kubernetes, JWT/OIDC, LDAP, Kerberos, AppRole, TLS certificates, tokens, userpass and login MFA |
| Storage backends and high availability | Stored in etcd; etcd should run with an odd number of members and a backup plan | Integrated storage (Raft) and PostgreSQL are the officially supported HA backends; confirm the topology for your site |
| Delivery into Pods | Mounted or exposed as environment variables; external delivery through the Secrets Store CSI Driver is a Kubernetes add-on to confirm | Delivered through application or agent integrations using the Kubernetes auth method; confirm the delivery pattern in your environment |
| License | Kubernetes is open source under Apache 2.0 | OpenBao is licensed under MPL-2.0 and is a Linux Foundation OpenSSF project |
What etcd defaults and RBAC exposure mean for Kubernetes Secrets
Two risks drive most of this decision, and both sit inside the cluster rather than in the application. The first is storage. Kubernetes Secrets are stored unencrypted in etcd by default, and anyone with API access or direct etcd access can read or modify them. Encryption at rest is a setting you must enable deliberately through the API server's encryption configuration, and the Kubernetes documentation expects administrators to do so. Ask your platform team whether it is enabled today, which key provider protects the encryption key, and who can read the etcd snapshots that your backup process produces, because those snapshots carry the same secret material.
The second risk is RBAC exposure, and least privilege alone does not close it. Anyone authorized to create a Pod in a namespace can read any Secret in that namespace, including indirectly by creating a Deployment that mounts the Secret. Illustrative example: a developer with rights to deploy workloads, but no rights to read Secrets, creates a Pod that mounts the database password and prints it to a log. Audit who holds create rights on Pods, Deployments and similar workload objects in each namespace, not only who can run get secrets. A secrets manager such as OpenBao does not remove this path on its own, but it lets you issue short-lived credentials instead of static values that sit in a namespace.
A secrets manager changes where the secret is stored, how it is issued and how it is revoked. It does not change the fact that the workload consuming the secret must run in a cluster you still have to protect. The pod that receives a credential, the node that runs it and the service account that authenticates to OpenBao all remain attack surfaces, and a leaked token is still usable until its lease ends. Plan for hardening of the consuming cluster, including the Pod Security Standards, and confirm with your security team how long an issued credential stays valid before you commit to a design.
Licensing: Apache 2.0 Kubernetes against MPL-2.0 OpenBao
Kubernetes is open source and licensed under Apache 2.0, so you can run, modify and redistribute it without a license fee from the project. Secrets are not sold as a separate product. They are a built-in API object that ships with Kubernetes, so there is no Secrets edition to buy or upgrade to. What varies is the distribution you run. The CNCF Certified Kubernetes conformance program checks that vendor and community distributions support the required Kubernetes APIs, and the CNCF page states there are over 90 Certified Kubernetes offerings. Conformance tells you the API surface is consistent. It does not tell you who supports your cluster, how long patches last or what the support contract costs.
- Apache 2.0 base: The upstream project carries no license fee for running Secrets, so your recurring cost sits with the distribution, managed service or your own staff.
- No separate Secrets edition: Encryption at rest, RBAC and external store integrations are configured in the cluster, not licensed as add-ons.
- Conformance is not support: A certified distribution meets the API checks, but support terms, patch windows and escalation come from the distribution vendor.
- Support windows are set by Kubernetes: Minor releases are maintained for a limited period, so the cluster upgrade plan drives how long your Secrets handling stays on a supported base.
Before you commit, ask your distribution provider for its support terms, patch commitments and any commercial tier in writing.
OpenBao is licensed under MPL-2.0 and is a community-driven fork of Vault. The Linux Foundation's OpenSSF stewards the project, and OpenBao is a Sandbox project of the OpenSSF. The MPL-2.0 license is file-level copyleft, so changes to MPL-licensed files must remain under MPL-2.0 when you distribute them, while your own separate code can carry a different license. Governance is run by a community under open-governance principles, which is the main reason many teams prefer it over Vault after HashiCorp's licensing change. Namespaces are documented for OpenBao as a way to isolate tenants within one instance. HashiCorp documents namespaces as part of Vault Enterprise, so the same capability is not gated behind a paid tier in OpenBao's documentation.
- MPL-2.0 license: The code is open source under a file-level copyleft license, which matters for redistribution and for any modifications you make to OpenBao files.
- OpenSSF stewardship: The Linux Foundation's OpenSSF hosts the project, and OpenBao holds Sandbox project status within the OpenSSF.
- Namespaces documented in OpenBao: Multi-tenant isolation within one instance is documented in OpenBao, while HashiCorp lists it as part of Vault Enterprise.
- No paid edition named in the facts: This research does not identify a commercial OpenBao edition or a paid support tier.
Confirm the commercial support terms with the OpenBao community's listed support providers or with DeployOpen in writing, and check the license text against your legal team's requirements.
Using both does not create a new license. Kubernetes stays under Apache 2.0 and OpenBao stays under MPL-2.0, and each keeps its own obligations. The license question becomes operational: which component you are responsible for supporting, and who you call when something breaks. A common pattern is to run OpenBao as the system of record for secrets and let Kubernetes workloads authenticate to it through the Kubernetes auth method, so pods receive short-lived credentials instead of long-lived values stored in etcd. Your licensing review then covers two separate components, each with its own support path.
- Two licenses to review: Apache 2.0 for the cluster and MPL-2.0 for OpenBao, each reviewed on its own terms.
- Two support paths: Your Kubernetes distribution provider and your OpenBao support source may be different parties with separate terms.
- Community support differs from contracted support: Community channels are not a support contract, so confirm response expectations for production incidents.
- Upgrade coupling: Kubernetes minor releases and OpenBao releases follow different schedules, so track both support windows.
Before you deploy, get written answers on commercial support for each component and confirm that your legal and procurement teams accept both license terms for your intended use.
Moving secrets from Kubernetes Secrets into OpenBao
This sequence moves static values and dynamic credentials out of etcd-backed Kubernetes Secrets and into OpenBao, with each workload switched over and verified before the old objects are removed. The result is one audited secrets source that both platform and application teams can control.
Inventory every Secret and its consumers
The platform team lists each Secret in the cluster, the namespace it lives in, the Pods, Deployments and operators that read it, and whether the value is a static credential (an API key, a pre-shared key, a certificate) or something that could be issued on demand, such as database access for an application. Application owners confirm which workloads depend on each object and how they consume it, as environment variables or mounted files. The step is done when the team holds a signed-off spreadsheet or manifest that maps every Secret to an owner, a consumer list and a target type: static path or dynamic engine. Secrets that no workload uses are flagged for deletion rather than migration.
Configure the Kubernetes auth method and roles
An OpenBao administrator enables the Kubernetes auth method and configures it to trust the cluster so that Pods can authenticate with their service account tokens. For each namespace, the administrator creates a role that binds specific service accounts to specific policies, following least privilege. Policies grant read access only to the paths that workload needs. The check is a test login from a Pod in each namespace that returns a token carrying only the intended policies, plus a denied read against a path outside that scope. Confirm the exact configuration against the Kubernetes auth method documentation for your OpenBao version before you apply it in production.
Migrate static values into OpenBao paths
The team writes each static value into a KV path that follows a naming convention by environment, namespace and application, so policies can be scoped cleanly. Values are copied from the existing Secret objects using a controlled process, with access limited to the migration operator and logs kept free of plaintext. Dynamic candidates are instead configured as dynamic secrets engines, such as a database engine with its own roles, rather than copied. The step is complete when each path reads back the expected keys and a test read from an authorized service account succeeds. Transfer covers the secret values themselves, but credentials that were ever exposed should be rotated as part of the cutover, not carried over unchanged.
Switch workloads to read from OpenBao
Teams choose one delivery method per workload and confirm it before changing manifests: a sidecar agent that writes secrets to a shared volume, an operator that syncs OpenBao values into Kubernetes objects, or the Secrets Store CSI Driver that mounts values through a provider. Each method has different rebuild effort, so the choice should be recorded with its owner. Deployments, Helm values, GitOps repositories and CI pipelines are updated to reference OpenBao paths instead of Secret names. Rolling restarts follow in a controlled order. The check is that each workload starts, passes its health checks and logs no authentication errors against the new source.
Run both sources in parallel and verify
For a defined window agreed by the owners, the old Kubernetes Secrets remain in place while workloads run on OpenBao-delivered values. Teams compare audit logs, confirm that every consuming workload is reading from OpenBao, and test failure paths, including a lease renewal and a rotated value picked up by a restarted Pod. Any object still read by a workload is found by reviewing API audit logs where they are enabled. The step closes when the owners sign off that no consumer depends on the old objects and that OpenBao audit logging is capturing every read, so that the migration evidence is retained.
Remove old Secrets and rotate affected credentials
The team deletes the old Kubernetes Secret objects, and removes any leftover copies in backups, Helm release history and CI variables where the platform allows it. Because Secrets in etcd were stored unencrypted by default, credentials that have been readable through API or etcd access should be rotated at the source, not just relocated. Rotation is coordinated with each owner and recorded. The check is an inventory query showing no remaining Secrets for migrated workloads and a rotation log that matches the step-one inventory. Keep the Kubernetes Secret manifests in version control only in encrypted or reference form, never as plaintext values.
Plan the reverse path before cutover
Before cutover, the team documents what reverting costs. Policies, roles, pipelines, Helm values and manifests that reference OpenBao paths must be rebuilt to point back to Kubernetes Secret names, and the OpenBao-side configuration becomes an orphaned dependency to retire. Dynamic credentials issued by OpenBao would need to be replaced with static values, which means new issuance and rotation work. Ask the OpenBao operator and your delivery-method vendor to confirm the rollback steps for your version, and keep the old Secret manifests until the verification step passes. This planning makes the reverse path a known, costed decision rather than an emergency.
What drives the running cost of each option
Kubernetes Secrets carry no separate license, but the cost sits in the cluster controls around them. OpenBao adds a service with its own storage, unsealing and policy work, so the running cost depends on what each team already operates and what it must maintain.
Kubernetes Secrets running costs
There is no separate license fee, so the recurring work is operational. Teams pay for etcd backups, for encryption at rest configured on the API server, for keeping least-privilege RBAC current as namespaces and workloads change, and for any Secrets Store CSI Driver integration with an external store. Ask who in your organization owns each of these tasks and how often they are reviewed.
OpenBao running costs
The software is MPL-2.0, so the cost is infrastructure and people. Budget for the cluster that runs OpenBao, its storage backend (integrated Raft or PostgreSQL), staff time for unsealing and recovery, policy and auth method configuration, and upgrades. Any support subscription is a separate line item that you must request from the provider or partner in writing.
Skills needed on each side
Kubernetes Secrets require cluster administrators who understand RBAC, encryption providers and etcd operations. OpenBao requires people who can run a Vault-style service: policies, auth backends, lease behavior, storage HA and seal management. Ask whether your current platform team already covers both sets of skills, because training and hiring time often costs more than licensing.
Upgrade cadence to plan for
Kubernetes releases come roughly three times per year on a cycle of about 14 weeks, according to the Kubernetes release cycle page, and the project maintains the three most recent minor releases. OpenBao's current lines are 2.7.1 and 2.6.4, both released on October 1, 2026, per the OpenBao GitHub releases page. Plan upgrade windows for both, since Kubernetes upgrades also affect how Secrets are stored and read.
One-time versus recurring costs
One-time work includes designing the secret model, wiring the Kubernetes auth method, migrating existing Secrets and writing policies. Recurring work includes etcd or storage backups, unseal procedures, upgrades, access reviews and any support contract. Ask a provider to split its quote into these two groups so you can see which costs continue after go-live.
Support options to request in a quote
Ask whether the scope includes implementation, initial hardening, backup and restore testing, upgrade support and documented runbooks for unsealing and recovery. Clarify response windows, who holds on-call responsibility and how the upgrade of OpenBao and Kubernetes are scheduled together. DeployOpen scopes these items in writing before work starts, and ongoing support is available as a retainer.
Where OpenBao rollouts usually run long
Running OpenBao alongside Kubernetes involves more design work than installing a chart. Teams need to choose a storage backend (integrated Raft storage or PostgreSQL, both officially supported for HA), decide how the cluster is unsealed after restarts, define policies that scope each secret path, and configure Kubernetes auth roles per namespace so that a workload's service account can only obtain the secrets it needs. After that come the workload migration, which means changing applications that read Secrets as environment variables or mounted files, and the audit and rotation process that keeps the system working after handover. A fixed-scope agreement should list each of these as a separate deliverable, so the reader can see what is included before work starts.
Most delays come from three gaps. The first is unclear ownership of unseal keys: if the Shamir key shares or the auto-unseal KMS or HSM access are not assigned to named people or roles before go-live, the team discovers during the first node restart that nobody can bring the cluster back. The second is workloads that assume static Secrets: applications that expect a fixed value in a Kubernetes Secret may need code or sidecar changes to handle leased, dynamic credentials that expire and are renewed, and that work is often underestimated because it sits with application teams rather than the platform team. The third is rotation work that was never scoped: rotation schedules, revocation procedures and the audit trail for leases are easy to describe and hard to finish without a named owner.
Before you sign a scope, ask the provider to show, for each item above, who owns it after handover, what document records it and how it will be tested. Confirm with your own platform and application teams which workloads read Secrets directly, and whether your compliance evidence needs the audit log to be retained in a particular system. Those answers, not a generic estimate, determine how much of the project the written scope has to cover.
Questions teams ask before choosing OpenBao or Kubernetes Secrets
Is encryption at rest enough to make Kubernetes Secrets safe?
No. Encryption at rest protects Secret values in etcd and in etcd backups, but it does not limit who can read a Secret through the API. Kubernetes Secrets are stored unencrypted in etcd by default, and anyone authorized to create a Pod in a namespace can read any Secret in that namespace, including indirectly by creating a Deployment. Teams still need to configure least-privilege RBAC, restrict list and watch access, and limit which workloads can mount Secrets. Encryption at rest is a necessary control, not a complete one. Confirm with your Kubernetes distribution how encryption configuration is set and rotated, since that varies by platform.
Can OpenBao run inside the same cluster it serves?
It can, but the design choice carries a dependency risk. If OpenBao runs in the cluster it protects, a cluster-wide failure can also take down the secrets service, and workloads may not start while it is unavailable. Many teams run OpenBao in a separate cluster, on dedicated VMs, or in a platform account, then reach it through the Kubernetes auth method. The right placement depends on your availability targets, your unseal process and who operates the cluster. Ask your platform team to document the failure mode for each option before deciding.
How much effort does an OpenBao rollout take, and what does it need from our team?
Effort depends on the number of secret engines, the auth methods you enable, the storage backend, the unseal model and how many applications change how they read secrets. The work includes running a highly available cluster, setting up backups, defining policies, moving existing Secrets and handling audit logging. Your team needs people who can operate Vault-compatible infrastructure, manage Kubernetes RBAC and own on-call for the secrets service. OpenBao documents integrated storage (Raft) and PostgreSQL as the officially supported HA backends. No duration is established here; ask any implementation partner for a written scope that lists each component and who operates it.
Can our own team do this work without outside help?
A capable platform team can deploy OpenBao and Kubernetes auth from the public documentation, especially for a single cluster and a small number of secrets. Outside help tends to matter more when you need hardened storage, unseal planning for air-gapped or multi-site sites, migration of many existing Secrets, integration with CI and GitOps, or evidence for an assessment. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with the scope and deliverables agreed in writing before work starts. Whether your team takes on the work depends on its skills and capacity, which only you can judge.
What does a quote for this work depend on?
A quote follows from a written scope, so it depends on the systems in scope and the decisions behind them. Key inputs include the number of clusters, the secret types (static key/value, dynamic database credentials, certificates or encryption as a service), the storage backend, the unseal method, the high availability design, the migration volume from existing Secrets, the integrations with CI, GitOps and identity providers, the documentation and the handover. DeployOpen does not publish a price list. Ask for the scope items, the assumptions behind each one, what is one-time and what recurs, and whether ongoing support is a separate retainer.
Are dynamic secrets worth the change from static Kubernetes Secrets?
They are worth it when credentials are long-lived, widely shared or hard to rotate. OpenBao provides dynamic secrets for systems such as Kubernetes and SQL databases, along with leasing with automatic revocation and bulk revocation, so a credential can expire and be revoked without editing manifests. Static Secrets are simpler and may be enough for low-risk values that rarely change. The cost is operational: applications must handle short-lived credentials and renewal, and the secrets service becomes a dependency for every workload that uses them. Test the lease renewal behavior in a non-production environment before you change production applications.
How do OpenBao and Kubernetes Secrets work together through the Kubernetes auth method?
OpenBao's Kubernetes auth method lets workloads authenticate with their Kubernetes identity, such as a service account token, and receive an OpenBao token with policies scoped to that identity. Applications then read secrets from OpenBao at runtime or through a delivery mechanism, instead of storing the values as native Secret objects. Many teams keep only non-sensitive configuration in Kubernetes Secrets, or sync selected values through an external store provider such as the Secrets Store CSI Driver, which Kubernetes documentation names as an option. Confirm the exact delivery pattern, token lifetimes and policy design with your platform team before rollout.
What should we confirm about the storage backend before choosing OpenBao?
Confirm which backend fits your operating model: integrated storage (Raft), PostgreSQL, PebbleDB or in-memory. The OpenBao storage documentation describes PostgreSQL as easier to operate safely than Raft, and integrated storage and PostgreSQL are the officially supported HA backends. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. Check backup and restore procedures, the database team's support model, network requirements and the upgrade path for your chosen OpenBao release line, currently 2.7.1 and 2.6.4 per the OpenBao releases page. Ask your vendor or implementation partner to test a restore before go-live.
How DeployOpen helps teams choose, implement or migrate
DeployOpen helps teams decide whether Kubernetes Secrets are enough or an external secrets manager such as OpenBao is needed, then plans, implements and hands over the chosen design inside the client's own clusters and infrastructure. Engagements are fixed-scope, with the scope agreed in writing before any work starts.
How we scope
- Written scope covers which workloads need secrets, who consumes them and where they run.
- We review etcd encryption at rest, RBAC exposure and namespace layout in your current clusters.
- Scope defines whether OpenBao, native Secrets with hardening, or both combined will be built.
How we build
- We configure OpenBao with the Kubernetes auth method, policies and dynamic secrets for agreed systems.
- We set up encryption at rest, least-privilege RBAC and restricted Secret access for the Kubernetes side.
- We test secret leasing, revocation and failure paths against the agreed design before handover.
How we hand over
- Deliverables include architecture notes, configuration files, runbooks and access policy documentation.
- We document storage backend, unseal approach and backup procedures agreed with your team.
- Your engineers receive walkthroughs so they can operate, review and extend the setup independently.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover tracking of OpenBao and Kubernetes release lines relevant to your environment.
- Compliance evidence for your assessment can be prepared, while independent auditors issue any formal opinion.
