Kubernetes secrets from OpenBao and Vault without leaving credentials in etcd
Pods need database passwords, API keys and certificates, and the team wants those values out of plain Kubernetes Secrets. The Secrets Store CSI Driver mounts secrets from an external store into pods through a provider for OpenBao or HashiCorp Vault, and Kubernetes auth in the secrets store decides which service accounts can read which paths. DeployOpen plans and builds this integration in your cluster and against your secrets store, so the design follows your namespaces, workloads and approval process. Before build, the exact provider plugin and driver versions must be confirmed against the Kubernetes version you run, because the driver and the provider release on their own schedules. The first design task is an inventory of which workloads need which secrets, since every later control depends on that list.
The reason this approach matters is where the secret values end up. According to the Kubernetes secrets good practices documentation, Secrets are stored unencrypted in etcd by default. Administrators can configure encryption at rest, restrict list and watch access with least-privilege RBAC, or use external stores through the Secrets Store CSI Driver. With the driver, a SecretProviderClass object names the provider, the store address and the secret paths, and the pod's service account token is used to authenticate to the store. The secret is delivered as a file on a volume that the kubelet mounts, so the value does not have to exist as a Kubernetes Secret object. Confirm the sync settings with your team early, because the driver can also copy values into Kubernetes Secrets, and any synced copy is written back to etcd.
Kubernetes auth in OpenBao or Vault is the control that carries the most weight. Bind each role to a specific service account and namespace, grant read access only to the policy paths that workload needs, and set token lifetimes short enough that a leaked token has limited use. OpenBao documents Kubernetes among its auth methods, and HashiCorp's Vault documentation covers the same pattern, but the configuration keys differ between versions, so confirm them with the vendor documentation for the versions you deploy. Decide early who owns role creation: a platform team that reviews every binding, or application teams that request bindings through a change process. Avoid wildcard service account bindings, because one broad role can expose secrets from many namespaces at once.
Rotation and availability change the operating model. The driver can refresh mounted files when a secret changes, but the application must reread the file or be restarted, and the refresh behavior depends on the driver version, so test it in a non-production cluster first. Plan for the store being unavailable as well. If the provider cannot reach OpenBao or Vault when a pod starts, the volume does not mount and the pod stays pending. That makes store availability a cluster dependency, so high availability for the store belongs in this design. Confirm that seal state is monitored and that a documented unseal procedure exists and has been rehearsed by the people who will run it.
A written scope should name the store edition and storage backend, the namespaces and workloads in scope, the secret paths and types to migrate, the rotation tests and the availability target for the store. Driver and provider versions should appear as a confirmed item in that scope, not as an assumption. List build work, handover and ongoing store operations as separate line items, because the cost of each recurs differently. Ongoing operations, upgrades and continuous testing can be covered by a retainer after handover. Ask for each component to be priced or estimated separately so you can compare the build against the effort your own team would need to carry.
What you need before connecting a cluster to OpenBao or Vault
Six items decide whether the integration works on the first attempt. Some are published by the Kubernetes, OpenBao, Vault and Secrets Store CSI Driver projects and need confirmation from them, while others are set in your own environment, including node layout, network rules and reviewer permissions.
Kubernetes version and release policy
Confirm that the cluster's minor version is one the Kubernetes project still maintains. The project supports the three most recent minor releases, and new minors arrive about three times a year, so check the current support list on the releases page before choosing a target. Confirm the version skew rules between the API server and kubelets as well, because the Secrets Store CSI Driver runs on every node. Schedule any pending cluster upgrade before the integration work so you do not build against a version that is about to leave support.
OpenBao or Vault service and version
Decide which product you run and record its exact version. OpenBao v2.7.1 and Vault 2.2.0 are the latest releases named in the release channels, but what matters is the version your environment runs and whether that line still receives fixes. Vault Enterprise features need a license applied to the cluster, so confirm which features your edition includes. Confirm licensing and support terms directly with the vendor or project before the design is fixed.
Storage backend and high availability design
Choose a storage backend that the product documents as supported for high availability. For OpenBao, integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and for Vault, integrated storage and Consul are the supported options. Decide how many nodes run, where the active node lock is held, and how a failed node or a lost data volume is recovered. Set backup and restore procedures in your own environment before any workload depends on the store.
Kubernetes auth method and reviewer permissions
Plan how pods prove their identity to the store. The Kubernetes auth method validates service account tokens with the cluster, so the store needs a reviewer identity that has only the permissions the token review step requires. Create a dedicated service account for the reviewer, bind it with least-privilege RBAC, and confirm the token and CA settings in the auth method documentation for your product version. Decide which namespaces and service accounts may log in and which policies each one receives.
Network paths and TLS trust
Map every connection the integration needs. The provider on each node must reach the store's API endpoint, and the store must reach the cluster API server when it validates tokens. Confirm the ports and load balancer paths through your firewalls and network policies, and install the CA chain that signs the store certificate into the trust path the provider uses. Document the control plane path on port 6443 separately, since it carries different traffic.
Secrets Store CSI Driver and provider versions
Match the Secrets Store CSI Driver and the OpenBao or Vault provider plugin to your Kubernetes version and to each other. Check the compatibility notes published by the driver and provider projects for your cluster release, and pin exact versions in your deployment manifests. Confirm with the project maintainers which combinations they support, and test any upgrade of either component in a non-production cluster first.
How the Secrets Store CSI Driver delivers secrets to pods
The Secrets Store CSI Driver delivers secrets by mounting them into pods as files, and the flow starts with a SecretProviderClass. This custom resource names the provider, which is OpenBao or Vault in this design, and lists the secret paths and keys the pod needs. It does not hold secret values. Its settings also describe how the driver authenticates to the provider, so the Kubernetes service account and the provider role it maps to become part of the access design from the first step. Review this object as carefully as the workload manifest that references it, because a broad path or an overly long object list gives every pod that mounts it more reach than it needs. Confirm the exact field names and supported options in the documentation for the driver release your cluster runs, since they change between releases.
On each node, the driver runs as a DaemonSet, and the provider runs alongside it as a component the driver calls. When kubelet starts a pod that references the volume, the driver requests the secret values from the provider using the identity configured for that pod. It then writes the values into a volume it manages on the node, and the pod sees ordinary files at the mount path. Because the fetch happens at pod start, a pod that cannot authenticate or cannot read a path fails to start, which makes configuration errors visible early. Ask your team to test these failure paths in a non-production cluster, including an expired provider role and a missing secret path, and to record what the pod events and driver logs show. Also confirm with your driver version whether the volume is memory-backed on the node.
Some applications read configuration from environment variables and cannot read a mounted file without code changes. For them, the SecretProviderClass can define secretObjects, which tells the driver to create a Kubernetes Secret from the fetched values. The pod then references that Secret in its environment variable configuration. The sync is tied to the mount: the driver creates the Kubernetes Secret when a pod mounts the volume. Confirm in the release notes for your version whether and when the driver removes the Secret after the last consuming pod stops, because cleanup timing affects who can still read the object after a workload is gone. Treat sync as an exception that a specific workload needs, not as the default path for every secret.
The synced Secret brings a copy of the value back into the cluster. Kubernetes stores Secrets unencrypted in etcd by default, according to the project's good practices guidance, so a synced object is only as protected as the cluster configuration around it. Before enabling sync, confirm that encryption at rest is configured for Secret resources in the API server and that the key management behind it meets your policy. Then restrict get, list and watch on Secrets with least-privilege RBAC, because anyone who can list Secrets in the namespace can read the synced values as easily as the application can. The mounted file path avoids this extra copy in etcd, which is the main reason to prefer files wherever the application can read them.
Make the delivery choice per workload and record it. Mount files by default, use sync only for workloads that need environment variables, and keep a short list of which namespaces and service accounts can read each synced object. Before go-live, check that the mounted files match the provider values, that a user without Secret read access cannot see the synced object, and that the pod fails visibly when the provider role is removed. Rotation and provider authentication need their own tests, so treat these checks as the baseline for those later tests rather than as a complete acceptance process.
Configuration sequence from store to pod
This sequence connects OpenBao or Vault to a Kubernetes cluster so that each workload receives only the secrets its own identity may read. Each step ends with a check, so the team confirms the trust path works before any application depends on it.
Confirm the cluster API endpoint and reviewer account
The platform team, working with the store administrator, records the cluster's API endpoint as the address OpenBao or Vault will call for token reviews, and confirms the store can validate the certificate that endpoint presents. They then create a dedicated service account for token review and grant it the cluster permission for token review (system:auth-delegator is the usual choice, but confirm it against your cluster version). The reviewer token and the cluster CA certificate are kept for the next step. Check: a manual token review sent with the reviewer token returns an authenticated result for a test service account token, which confirms the network path, certificate chain and permissions.
Enable and configure the Kubernetes auth method
On the OpenBao or Vault server, the administrator enables the Kubernetes auth method at a path that matches your naming convention, then sets the API endpoint, the cluster CA certificate and the reviewer token from the previous step. TLS verification stays on, and the cluster CA is supplied so the store validates the API server on every review. Confirm the configuration against the auth method documentation for your store version, since option names can change between releases. Check: reading the auth configuration back shows the expected host and CA, and a login with a test service account token returns a client token whose identity matches that service account.
Write a policy for each application path
Each application gets its own policy granting read access to its own secret path, usually under a prefix that names the team or application. Policies are written in the store's policy language and kept in version control, so every change goes through review. Avoid wildcards that span other teams' prefixes, because a broad path grant undoes the isolation the rest of the sequence builds. Check: a token issued under this policy reads its own path, and the same token is denied when it attempts to read a sibling application's path. Run both tests before continuing.
Create a role for one service account
The administrator creates an auth role that names one service account and one namespace, attaches the policy from the previous step and sets a short token lifetime suited to the workload. Binding to exact names matters: a wildcard lets any workload that matches the pattern obtain the same secrets. The role is the only link between a Kubernetes identity and a policy, so it is documented next to the application's manifests. Check: a login from the named service account in the named namespace succeeds, and a login from another service account or another namespace in the same cluster is rejected.
Install the Secrets Store CSI Driver and provider
The platform team installs the Secrets Store CSI Driver into a system namespace, then installs the provider that matches the store. OpenBao and Vault each need a provider that supports their API and auth flow, so confirm with the provider project which release works with your store version and your Kubernetes version. The driver and provider run on every node, so confirm that the namespace's Pod Security settings and admission policies allow these components to run. Check: driver and provider pods are ready on every node, and the CSI driver is registered with the kubelet on each node.
Define a SecretProviderClass for the workload
The team writes a SecretProviderClass in the same namespace as the workload. It names the provider, the store address, the auth role from step four, and the secret paths and object names to mount. If the application also needs a Kubernetes Secret, the sync option creates an object in etcd, and Kubernetes stores Secrets unencrypted there by default, so confirm encryption at rest and tight list and watch permissions before enabling sync. Check: the manifest applies without error, and its description shows the expected role and path, with no secret values stored in the manifest.
Deploy a test pod and verify access
The team deploys a test pod that runs under the named service account in the named namespace and mounts the SecretProviderClass. The pod is the final proof that the chain works from store to container. Check three results: the pod starts and the secret file appears at the mount path with the expected value; the pod can read only its own path; and a pod in another namespace, or one that uses a different service account, is denied when it references the same class. Confirm the store's audit log records these logins, then remove the test pod and any test secrets.
How Kubernetes identities map to secrets store paths and policies
This table traces one workload from its Kubernetes identity to the OpenBao or Vault objects that grant it access. Read each row as a link in the chain: the namespace, service account and labels identify the caller, the auth role and audience constrain the token, and the path and policy define what it can read. Record the owning team beside each mapping so access reviews and rotation alerts reach someone who can act on them.
| Mapping element | What to set | What to record or confirm |
|---|---|---|
| Namespace, service account and labels | Bind the role to one named service account in one named namespace. Labels select which SecretProviderClass a workload uses; they grant no access alone. | Namespace owner signs off the binding, and the role definition is kept in version control. |
| Auth role name | One role per workload and environment, named so audit logs identify the consumer, for example payments-api-prod (illustrative). | Confirm the naming convention with the security team before the first role is created. |
| Bound audience | The projected service account token must carry the audience the provider expects. Tokens with other audiences should be refused. | Confirm the exact audience string for your OpenBao or Vault version and provider build. |
| Secrets engine path | A KV v2 mount per team, with each application under its own path, for example teams/payments/api (illustrative). | Dynamic database or PKI engines get their own mounts and roles, listed separately. |
| Policy capabilities | Read on the data path for the role. List only where the workload enumerates keys. Renew only for leased credentials. | No write or delete for workloads. Record each capability with its reason in the policy file. |
| Lease or TTL behavior | Static KV values carry no lease the way dynamic credentials do. Dynamic credentials are revoked when their lease ends. | Ask the owning team for the TTL and maximum TTL per role. Confirm how the driver refreshes mounted values after a change. |
| Namespace or path prefix | Group paths under a prefix per team or environment so one policy can match them. Namespaces separate tenants where supported. | Vault lists namespaces as an Enterprise feature; confirm support for your edition. |
| Kubernetes Secret name when sync is enabled | Set the name in the SecretProviderClass. Use a name tied to the consuming workload so the Secret is easy to trace. | Synced Secrets sit in etcd, where Kubernetes stores them unencrypted by default. Confirm encryption at rest and RBAC. |
| Owning team | Name the team that approves role, policy and path changes and receives rotation or expiry alerts. | Keep the owner in the mapping file and review it at each access review. |
Choosing between OpenBao and HashiCorp Vault for pod secrets
Licensing and governance should settle the store choice before any manifest is written. OpenBao is licensed under MPL-2.0, is led by a community run under open-governance principles, and is a Sandbox project of the Open Source Security Foundation under Linux Foundation stewardship. HashiCorp announced on August 10, 2023 that future releases would move from MPL-2.0 to the Business Source License 1.1. The Vault LICENSE names IBM as licensor, applies to Vault 1.15.0 and later, bars competitive hosted or embedded offerings, and converts each version to MPL-2.0 four years after publication. IBM completed its acquisition of HashiCorp on February 27, 2025. Ask your legal and procurement teams to review these terms against how you plan to run, share and possibly embed the secrets platform, and record the decision with its reasons.
The second question is which features your design depends on. HashiCorp's Vault Enterprise documentation lists namespaces, performance standby nodes, seal wrapping, FIPS compliance, HSM support with a PKCS#11 provider, replication, control groups, Sentinel policy as code and MFA as features that need a license applied to the cluster. Write down the features your target design uses. If you need namespaces to isolate teams, performance standbys to scale reads or seal wrapping for key protection, Community Edition is not a fallback that matches that design. OpenBao documents namespaces too, so confirm that its implementation covers the behavior you need. HashiCorp's pricing pages direct self-managed Enterprise buyers to sales, so request a written quote that states the license tier, term, support level and included products.
If you are moving existing secrets from Vault to OpenBao, read the migration guide closely before you set a change window. The guide was tested only against Vault 1.14.1 Community Edition, so Vault Enterprise deployments need separate confirmation. Your source deployment may differ in version, edition, storage backend, seal configuration and enabled auth methods. Check especially the Kubernetes auth method, AppRole and JWT/OIDC, because the CSI integration depends on them. Run the migration on a copy of your data in a non-production cluster that matches production, log each difference you find, and confirm with the project or your support channel any step the guide does not cover for your setup. Keep a rollback path for the period when pods may still read from the old store.
Pin versions before you compare behavior. The current OpenBao release line includes v2.7.1, released on October 1, 2026, and v2.6.4 for the previous minor line, released the same day. The current HashiCorp Vault release is 2.2.0, released on October 15, 2026, following 2.1.2 on October 7, 2026. Choose the store version you will run in production, then confirm that the Secrets Store CSI Driver provider plugin supports that store and that version, along with the CSI driver release and the Kubernetes version in your cluster. Provider support is the item most likely to change between releases, so test the full chain together in a staging cluster and recheck it before every upgrade of any component.
Hardening the secrets path from store to pod
The secrets path has three hops: the store, the Secrets Store CSI Driver on each node, and the Kubernetes objects it creates. Each hop needs its own controls, and a weakness in one can undo the others. The cards below cover the decisions that matter most, from certificate trust and store policy through namespace boundaries, cluster RBAC, etcd encryption and key protection.
TLS and certificate trust for the store
The CSI provider only fetches secrets from a store whose TLS chain it trusts. Issue the store certificate from an internal CA, load that CA into the provider configuration, and confirm the certificate names match the address the provider calls. Test certificate rotation before go-live, because an expired store certificate stops every mount at once. Restrict who can change the CA bundle, since a swapped bundle could let a spoofed store serve secrets.
Least-privilege policies per application path
Give each application path its own store policy that allows read on that path and nothing above it. Avoid wildcard paths that reach other teams' secrets, and do not grant list or write where the workload only needs to read. Review the policy each time a new SecretProviderClass maps a pod to a path. Keep policy files in version control so every change passes through review and leaves a record.
Namespace boundaries and exact role bindings
Bind each store auth role to one namespace and one service account name, with no wildcard for either. A role bound to a broad namespace pattern lets any workload there request that role's secrets. Enforce Pod Security Standards on each workload namespace, aiming for Restricted and accepting Baseline only where workloads cannot yet meet it. Confirm the enforcement labels are present, because a namespace without them has no pod security check.
Restricting SecretProviderClass creation
A SecretProviderClass tells the driver which store path to fetch and which Kubernetes Secret to sync. Anyone who can create or edit one can point a pod at a path the team never intended to expose. Limit create, update and patch on these objects to the platform group, and have application teams request changes through a reviewed pipeline. Audit the RBAC roles in each namespace to confirm that no default or shared role grants this access.
Encryption and read access for synced Secrets
Kubernetes stores Secrets unencrypted in etcd by default, so syncing secrets into the cluster moves the exposure into the control plane. Configure encryption at rest for etcd, with a key source your policy approves, and confirm that existing Secrets were re-encrypted after the change. Restrict get, list and watch on Secret objects to the workloads and operators that need them, because list and watch expose every value in a namespace.
Unseal keys and audit logging
The unseal or auto-unseal method decides who can open the store after a restart, so its key material needs the same protection as the secrets. Keep unseal keys in a key service or HSM that you control, separate from the store's storage, and document who can access them. Enable an audit device on the store, forward its logs outside the cluster, and pair them with Kubernetes API audit logs so a secret read can be traced from pod to store request.
How secret rotation and lease renewal reach running pods
Dynamic secrets from OpenBao or Vault are issued with leases, and a lease expires. The team has to decide, before go-live, how a changed value reaches the application. There are three common paths: the application re-reads a mounted file, the pod restarts, or the workload controller performs a rolling update. A file re-read keeps the pod running but only helps if the application loads the file again without a restart. A restart is simple to reason about but interrupts traffic unless replicas are staggered. A rolling update through the Deployment, StatefulSet or DaemonSet controller gives a controlled replacement, but it needs a trigger that changes the pod template. For each workload, record which path it uses and who owns the reload logic.
The Secrets Store CSI Driver's rotation behavior depends on the driver version in your cluster and on how it was installed. Rotation settings, the re-sync interval and whether synced Kubernetes Secrets update all change between releases, so confirm the behavior in the documentation for your exact version rather than assuming it. One detail matters in every case: an environment variable populated from a Kubernetes Secret is set when the container starts and does not change afterward. If a workload reads its database password from an environment variable, a synced Secret update will not reach it without a restart. Test this with the version you run and pin it so that an upgrade does not change the behavior silently.
Renewal is a separate concern from rotation. A lease must be renewed by a client or agent before its time-to-live ends, or the credential stops working. Confirm which component performs renewal for each secret path, whether that is the application, a sidecar agent or the provider in the CSI pipeline, and what happens when renewal fails. Ask whether each pod mount creates its own lease, because that multiplies lease counts across replicas. Lease count limits are a licensed feature in Vault Enterprise, so check the quota behavior if you run that edition. OpenBao documents leasing with automatic revocation, which makes renewal failures visible as expiry events that your monitoring should alert on.
Revocation has two effects that teams often mix up. Removing a Kubernetes service account binding or a role in OpenBao stops future logins, but it does not automatically end credentials already issued, unless you also revoke the leases. Revoking a lease, or using bulk revocation, ends the credential at the target system, and any pod still holding it will fail on its next request. Before removing a role, list the workloads and leases that depend on it, move consumers to the replacement role, and only then revoke. Write this order into the runbook, because the failure appears in the application, not in the secrets store.
Test rotation in a non-production namespace before production. Create a test role with a short time-to-live in a test environment, mount the secret into a sample deployment that matches a production workload, and record the driver and OpenBao or Vault versions. Then check four things: whether the file changes, whether the application reloads it, whether a restart or rolling update path behaves as designed, and what happens when the lease is revoked. Repeat the test before any driver upgrade, OpenBao minor version upgrade or change to the Kubernetes auth role. Keep the results with the change record, so the production runbook reflects what was actually observed.
Common failures when pods cannot read secrets from OpenBao or Vault
This table lists the failures teams most often hit when pods read secrets from OpenBao or Vault through the Secrets Store CSI Driver, with the likely cause and fix for each. Start from the symptom in the first column, then check the cause to find which component is failing. Most failures trace back to a mismatch between the pod's identity, the auth role, the provider configuration or the driver version.
| Failure | Cause | Fix |
|---|---|---|
| Pod stuck in ContainerCreating | The volume fails to mount because the SecretProviderClass is missing, misnamed or in another namespace, or no provider runs on the node. | Read mount events with kubectl describe, confirm the class name and namespace match the pod, and check the provider pod on the node. |
| Permission denied from the store | The auth role binds a different service account or namespace than the pod actually uses. | Set the role's bound service account and namespace to the pod's actual values, then test login with that service account token. |
| Token review errors | The auth method points at the wrong Kubernetes API endpoint, or the reviewer token is missing, expired or lacks TokenReview rights. | Set the API endpoint the store can reach, and give a reviewer service account permission to create TokenReview objects. |
| TLS verification failures | The store does not trust the private CA that signed the Kubernetes API or the OpenBao or Vault listener certificate. | Add the CA bundle to the auth method and the provider configuration, then verify the certificate chain from inside the cluster. |
| Expired leases not renewed | Dynamic credentials expire while the application keeps using the value it read at startup. | Confirm the lease TTL and renewal behavior, have the application reread the mounted file, or restart the workload on rotation. |
| Kubernetes Secret not updated after rotation | The synced Secret refreshes only while a pod mounts the volume, and env vars never refresh without a restart. | Keep a pod mounting the volume, enable rotation in the driver, and roll workloads that read the synced Secret as environment variables. |
| Provider version does not match the driver | The provider image expects a different driver interface after one component is upgraded and the other is not. | Upgrade the driver and provider together using the versions in the provider's compatibility notes, then restart affected pods. |
Questions buyers ask before connecting Kubernetes to OpenBao or Vault
What drives the cost and effort of connecting Kubernetes to OpenBao or Vault?
The main drivers are the number of workloads that read secrets, the number of secret paths and policies, rotation requirements, whether values must sync into native Kubernetes Secrets, the store topology and high availability design, and the number of clusters. Each one adds design, configuration, testing and handover work, and several multiply together, so a cluster with many workloads and frequent rotation costs more to connect than a small cluster with static values. DeployOpen works from a written scope, and most engagements are fixed-scope. Ask any quote to state these counts explicitly so you can compare it with your own estimate and see what changes if the counts grow.
Is connecting Kubernetes to a secrets store a one-time project?
The initial build is one-time. It covers store authentication for Kubernetes, the Secrets Store CSI Driver and provider installation, SecretProviderClass objects, store policies and roles, and test workloads that prove mounts, sync and rotation behave as designed. Work that recurs includes upgrades to the store, the CSI driver and Kubernetes itself, policy changes as teams add or retire applications, rotation reviews, and backup and restore checks for the store. Teams that want these handled over time can use a retainer for ongoing support, upgrades and testing. Ask the quote to separate one-time build effort from recurring operations so you can budget for both.
What must our team provide before a secrets integration project starts?
You need four things. First, cluster admin access, so the driver and its service accounts can be installed and configured. Second, store admin access, so Kubernetes authentication, policies and roles can be created and tested. Third, a named owner for each application who approves which secret paths it may read and who agrees to rotation timing. Fourth, test workloads in a non-production cluster that mirror the production pattern, so mounts, syncs and rotation can be verified before anything changes in production. Also agree on change windows for each environment. Missing owners are one of the most common causes of delay, because policy decisions cannot be made without them.
Can our own team connect Kubernetes to OpenBao or Vault without a partner?
Yes, if you have administrators for both Kubernetes and the secrets store. The integration uses documented open-source components, but it depends on working knowledge of RBAC, service accounts, Kubernetes authentication, store policies and how the CSI driver mounts volumes. A partner adds the most value in planning the secret path model, reviewing the design for least privilege, testing failure cases such as store outages, and writing the runbooks your operators will use. Teams often build the core themselves and bring in a partner for design review or testing. Confirm your skills on both sides before deciding, and name the people who will own the integration after handover.
How does choosing OpenBao or Vault change the project scope?
The Kubernetes integration pattern is broadly similar, but the scope differs in licensing, features and migration. OpenBao is licensed under MPL-2.0 and is a Sandbox project of the OpenSSF under Linux Foundation stewardship. HashiCorp announced in 2023 that future Vault releases would use the Business Source License 1.1, and the Vault license names IBM as licensor. Vault Enterprise features such as performance replication, HSM support, namespaces and Sentinel policy as code require a license applied to the cluster. If your design depends on them, they belong in scope. OpenBao's migration guide was tested only against Vault 1.14.1 community edition, so confirm compatibility for your exact version before planning a move.
How much does Vault Enterprise cost for a Kubernetes integration?
HashiCorp does not publish Vault Enterprise prices for direct self-managed buyers. Its pricing pages describe pay-as-you-go, flex and Enterprise self-managed commercial models, and direct Enterprise buyers are directed to HashiCorp sales for a quote. Treat the license as a separate purchase from the implementation work. Ask HashiCorp which edition and features your design needs, what the license term covers, and whether a managed option such as HCP Vault Dedicated fits your data residency needs. DeployOpen's implementation quote follows from the written scope and does not include the cost of a Vault Enterprise license, so keep the two quotes separate when you compare options.
Does Kubernetes keep secrets safe without an external secrets store?
Not by default. Kubernetes stores Secrets unencrypted in etcd unless you configure encryption at rest, and anyone with list or watch access to Secrets in a namespace can read their values. An external store reduces that exposure when pods mount values directly through the Secrets Store CSI Driver, because the values need not persist in etcd. Syncing values into Kubernetes Secrets brings them back into etcd, so decide per workload whether that is acceptable. Whichever pattern you choose, configure encryption at rest for etcd, restrict list and watch access with least-privilege RBAC, and confirm the design with your security team and the controls your framework expects.
How does the OpenBao storage and HA design affect Kubernetes workloads?
The store is in the startup path for pods that mount secrets, so its availability affects deployments and restarts. OpenBao's officially supported HA backends are integrated storage (Raft) and PostgreSQL. In an HA setup, one active node holds a lock in the data store, and standby nodes forward or redirect requests. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and 2.7.0 extended that to PostgreSQL. Confirm which backend fits your operations team, how many clusters will depend on the store, and how the CSI provider behaves during a store outage. Test those failure cases in a non-production environment before go-live.
How DeployOpen scopes and delivers this integration
DeployOpen plans the path from a secrets store to pods in your cluster as one written scope. That scope covers the OpenBao or Vault choice, Kubernetes auth in the secrets store, the Secrets Store CSI Driver configuration, and the rotation and handover steps. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Written scope that names the secrets store, the OpenBao or Vault edition, and the clusters in scope
- Decision record covering whether workloads read mounted files, synced Kubernetes Secrets, or both
- Inventory of secret paths, policies and service accounts each workload needs, agreed before any build starts
How we build
- Kubernetes auth roles in the secrets store, bound to specific namespaces and service accounts
- Secrets Store CSI Driver and provider configuration, with SecretProviderClass objects tested against real pod mounts
- Encryption at rest for etcd and least-privilege RBAC on any synced Kubernetes Secrets objects
How we hand over
- Runbooks for secret rotation, lease renewal and recovery of the secrets store and its storage backend
- Test evidence showing pods receive rotated values, with documented behavior when the store is unreachable
- Written auth configuration and policies, prepared for review by your security and compliance teams
How we support
- Retainer options for upgrades to OpenBao or Vault releases, tracked through your own change process
- Ongoing support for provider, driver and Kubernetes version changes as your clusters are upgraded
- Confirm Vault license terms for your use before choosing it, since 1.15.0 and later use the Business Source License
