Why Kubernetes secrets management with OpenBao is different in regulated clusters
A platform team running regulated workloads on Kubernetes needs more than the native Secrets object. By default, Kubernetes stores Secrets unencrypted in the API server's data store (etcd), and anyone with API or etcd access can read them. Anyone allowed to create a Pod in a namespace can also read every Secret in that namespace. For a cluster that handles ePHI, cardholder data or customer financial records, that is an access and audit gap before any application code runs. OpenBao is the open source option to evaluate for self-hosted secret storage, because it encrypts secrets before they reach storage and keeps custody inside your own infrastructure.
The Kubernetes documentation recommends encryption at rest for Secrets, least-privilege RBAC on list and watch verbs, restricting Secret access to specific containers, and considering external secret stores. OpenBao fits that recommendation, but the design choices still have to be made against your audit rules: which auth method pods use to log in (the Kubernetes auth method, with service account identity), how secrets reach the workload (an injector, the Secrets Store CSI Driver, or the application calling the API directly), and where OpenBao itself runs, on the cluster or off it. Each choice changes who can read what and what the audit trail shows. The Kubernetes secrets good practices page is the baseline your auditors are likely to compare against.
OpenBao is published under the MPL-2.0 license, which is an OSI-approved open source license, and it is a fork of Vault that is hosted under the OpenSSF. Our short answer on platforms: choose OpenBao for self-hosted secrets on Kubernetes, and evaluate Infisical as an alternative if your team prefers its feature set and its MIT-licensed core fits your review. Confirm with each vendor which features you need, such as dynamic database credentials or the exact Kubernetes integration path, because support differs by version and by edition.
Which regulatory requirements shape the Kubernetes secrets design
This table maps two US rules to concrete Kubernetes and OpenBao build decisions, so you can see which design choice answers which requirement. Read each row as a question to confirm with your compliance lead, because neither rule names OpenBao or Kubernetes and applicability depends on your entity type. The main takeaway is that per-workload identity, encryption at rest for etcd, audit logging and TLS between pods and OpenBao are the design points these rules most directly touch.
| Requirement | What it asks for | Build decision in Kubernetes with OpenBao |
|---|---|---|
| HIPAA access control (45 CFR 164.312) | Limit access to systems holding ePHI to authorized users and software | Give each workload its own Kubernetes service account bound to a narrow OpenBao policy, and restrict Secret read access with RBAC |
| HIPAA unique user identification (45 CFR 164.312) | Assign a unique identifier to each user of ePHI systems | Avoid shared service accounts and shared OpenBao tokens; confirm how human operators authenticate with unique identities |
| HIPAA person or entity authentication (45 CFR 164.312) | Verify that a person or software is who it claims to be | Use the OpenBao Kubernetes auth method so pods authenticate with their service account token, not a static password in a manifest |
| HIPAA audit controls (45 CFR 164.312) | Record and examine activity in systems containing ePHI | Enable an OpenBao audit device and forward it to your log platform; confirm how Kubernetes API audit logging is configured for Secret access |
| HIPAA transmission security (45 CFR 164.312) | Protect ePHI and credentials moving across networks | Terminate TLS between pods and OpenBao and confirm that the injector or CSI driver path does not send secrets in plaintext |
| FTC encryption at rest (16 CFR 314.4) | Encrypt customer information stored on systems | Enable encryption at rest for Kubernetes Secrets in etcd and keep OpenBao storage encrypted; confirm key custody for the encryption configuration |
| FTC multi-factor authentication (16 CFR 314.4) | Require MFA for individuals accessing information systems | Require MFA for human access to the Kubernetes API and OpenBao login, including operator and break-glass accounts; confirm which login paths support it |
| FTC activity logging (16 CFR 314.4) | Monitor and log the activity of authorized users | Log Kubernetes API requests, OpenBao audit events and secret reads to a central store with retention set by your policy |
Choosing how pods receive secrets: auth method, injector or CSI
With the Kubernetes auth method, the workload itself logs in to OpenBao using its service account token. OpenBao checks that token against the cluster's API, maps the service account and namespace to a policy, and returns a short-lived OpenBao token. The application (or a small helper library) then reads the secret directly. Nothing is pre-created in Kubernetes, so there is no copy in etcd unless your team chooses to write one. The OpenBao auth methods documentation lists Kubernetes among the supported methods, which makes this the baseline pattern to compare the others against.
- Who authenticates: the pod, using its projected service account token, against the OpenBao Kubernetes auth role.
- What lands on disk or in etcd: only the secret values the application chooses to write to its own memory or files. The secret is not stored in etcd by this pattern.
- Rotation behavior: the application must re-read the secret or renew its OpenBao token before the lease ends. Confirm how your chosen client library handles renewal.
- Policy scope: bind each role to specific service accounts and namespaces so that other pods in the same namespace cannot read the secret.
- Application changes: the code must call OpenBao, which is more work for legacy applications that read environment variables.
Confirm the exact auth role configuration and token renewal behavior in the OpenBao Kubernetes auth documentation for your version.
The injector pattern adds a helper container to the pod, usually through a mutating admission webhook. The helper authenticates to OpenBao with the pod's identity, fetches the secrets named in annotations, and renders them as files in a memory-backed volume shared with the application. The application reads a file or environment-style value and does not need to know about OpenBao. This suits applications that cannot change their code, but it moves complexity into the cluster's admission and sidecar configuration.
- Who authenticates: the injected helper container, using the pod's service account, not the application process.
- What lands on disk or in etcd: rendered secret files in the pod's volume. Use an in-memory volume where possible so values are not written to node disk. Confirm this behavior for your injector version.
- Rotation behavior: the helper can refresh rendered files as leases change, but the application may only read them at startup. Confirm whether your application reloads files on change.
- Operational footprint: every pod gets an extra container, which adds resource use and a new component to patch and monitor.
- Injector support: confirm the OpenBao injector status and supported Kubernetes versions with the OpenBao documentation before you commit to this path.
Confirm injector support and the file rendering options with the current OpenBao and injector documentation before you design around them.
The Secrets Store CSI Driver mounts secrets from an external store into the pod as a volume through a provider plugin. The pod's volume mount triggers the fetch, so the secret appears as files at a path the container reads. The driver can also sync selected values into a Kubernetes Secret when workloads need the native object, such as for an environment variable. Kubernetes' good-practices guidance names the Secrets Store CSI Driver as one way to use an external store, which is why many platform teams evaluate it first.
- Who authenticates: the kubelet and driver, typically with the pod's service account, through the provider configured for the store.
- What lands on disk or in etcd: files in a tmpfs-backed mount, and optionally a synced Kubernetes Secret in etcd. Syncing reintroduces the etcd exposure you were trying to avoid, so turn it on only where a workload requires it.
- Rotation behavior: the driver can rotate mounted content on a polling interval, but the synced Kubernetes Secret and the application's reads depend on configuration. Test the full rotation path.
- Provider dependency: confirm that an OpenBao provider exists for the driver version you run, and what authentication it supports, with the driver and OpenBao documentation.
- Encryption at rest still matters: if any Secret objects exist in etcd, enable encryption at rest and restrict list and watch access with least-privilege RBAC.
Confirm provider availability, sync behavior and rotation semantics with the Secrets Store CSI Driver and OpenBao documentation before you approve the design.
How dynamic database credentials reduce standing access
Dynamic database credentials replace a shared, long-lived database password with a credential that OpenBao creates when a workload asks for it and revokes when its lease ends. In a Kubernetes setup, the pod authenticates to OpenBao through the Kubernetes auth method, its policy allows it to read a database secrets engine role, and OpenBao returns a unique username and password for the database. Because leasing includes automatic revocation and bulk revocation, a compromised or retired pod loses database access without anyone rotating a password that every replica depends on. The reader should confirm which SQL engines their database team needs and how each role's creation and revocation statements are written, since those statements decide what a leaked credential can do.
The audit trail changes in a useful way. Each lease is tied to the identity that requested it, so the log can answer which service account in which namespace obtained which database user, and when. A shared password hides that answer. To make this work, reviewers should check that OpenBao audit devices are enabled and that the logs reach the team's SIEM, and that the Kubernetes service account names used in auth roles are specific enough to map to one workload rather than a broad group. Confirm also that the database user names OpenBao generates can be matched to the lease IDs in the audit log during an investigation.
The application has to handle the credential's lifetime. Depending on the integration, the pod either renews its lease before it expires or re-reads a fresh credential, and the connection pool must close old connections and open new ones without failing requests. Test this before production: force a lease to expire and confirm the workload recovers, revoke a role's leases in bulk and confirm the pods re-authenticate, and simulate an OpenBao outage to see how long the application keeps working on its existing credentials. Also confirm what happens if the database is unreachable during revocation. These tests show whether dynamic credentials reduce risk or just move the outage somewhere else.
Which platforms fit this pattern and why
Kubernetes secrets management needs a store that sits outside the cluster's default Secret model, a way for pods to authenticate without static credentials, and a license the organization can live with for years. The cards below cover the main options and the checks that separate them in practice.
OpenBao as the self-hosted store
OpenBao is an MPL-2.0 licensed secrets manager hosted under the OpenSSF, currently in its Sandbox stage. For Kubernetes, its Kubernetes auth method lets pods log in with their service account identity instead of a stored token, and its dynamic secrets can issue short-lived database credentials. Its wider feature set includes encryption as a service and PKI, which can cover certificates for the same cluster. Confirm which Kubernetes auth configuration, injector or CSI approach and HA storage backend your chosen delivery pattern requires, and confirm how the Sandbox stage affects your own support expectations.
Infisical with Kubernetes integration
Infisical is an open source platform for secrets, certificates and access, licensed under MIT except for content in ee directories, which carries a separate enterprise license. It can be a fit for teams that want a secrets console alongside Kubernetes workloads, but the Kubernetes integration method (operator, sync or injection) and its feature availability must be confirmed for your version. Check which features sit in ee directories before you rely on them, and check whether your audit and access controls need functions that are only in the enterprise license.
Native Kubernetes Secrets with encryption at rest
Native Kubernetes Secrets are a baseline, not a complete answer. By default they are stored unencrypted in etcd, and anyone who can create a Pod in a namespace can read any Secret in it. Enabling encryption at rest, applying least-privilege RBAC on Secrets and restricting access to specific containers reduce the exposure. Teams still need a separate source of truth, rotation and audit for values, which usually means pairing native Secrets with an external store such as OpenBao through the Secrets Store CSI Driver.
External store through the CSI Driver
The Secrets Store CSI Driver mounts secrets from an external provider into pods as volumes, so values can come from OpenBao without being created as Kubernetes Secret objects, although some setups still sync them into Secrets. Compare this with sidecar injection on rotation behavior, pod restart requirements and how failures in the provider affect pod startup. Confirm with the OpenBao provider documentation that your provider version supports the Kubernetes auth flow you plan to use.
Vault 1.15.0 and later under BSL
HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1, with IBM named as licensor. The BSL is not an OSI-approved open source license. Teams with an existing Vault estate should review their license terms, their use case and whether the Kubernetes integration patterns in this guide are used in the same way. Ask a migration partner to confirm the migration path and any licensing questions with the vendor or legal counsel before planning a move to OpenBao.
Rollout phases and the output of each
The sequence moves from measuring today's exposure to a tested OpenBao deployment that workloads read from, with each phase closing on a named artifact. Work proceeds in this order so that no static Secret is removed before its consumers and recovery path are proven.
Inventory Secrets, consumers and encryption status
The team lists every Secret object across namespaces, the Pods, Deployments and operators that mount or read each one, and whether the cluster API server encrypts Secrets at rest in etcd. Kubernetes stores Secrets unencrypted by default, so this check tells you how much is exposed today. The output is a register of Secrets with owner, consumer, namespace, rotation status and encryption state, reviewed and signed off by the platform and application owners.
Enable encryption at rest and tighten Secret RBAC
The platform team enables encryption at rest for Secrets in the API server configuration, then reviews RBAC so that only the service accounts and administrators that need Secret access can list, watch or get them. Kubernetes documentation specifically warns that anyone who can create a Pod in a namespace can read Secrets in it, so Pod creation rights are reviewed alongside Secret rights. The output is a verified encryption configuration, a before and after RBAC report, and a list of roles removed or narrowed.
Stand up OpenBao HA and audit logging
The team deploys OpenBao in high availability mode on a storage backend the team can operate, either integrated Raft storage or PostgreSQL, which OpenBao documents as officially supported HA options. Audit devices are enabled and forwarded to the log platform so every secret read and auth event is recorded. The output is a running cluster, a documented unseal and recovery key custody process, and a test showing that a standby takes over when the active node is stopped.
Configure Kubernetes auth roles per namespace
Engineers enable the Kubernetes auth method and create one role per namespace and workload, binding each role to a specific service account, namespace and a narrowly scoped policy. Workloads authenticate with their own service account token, so no shared credential is handed to pods. The output is a role and policy map, reviewed by security, showing which identity can read which path, plus test logins from each role that confirm nothing outside its scope is readable.
Migrate one non-critical workload first
The team selects a low-impact workload with a known Secret, changes it to fetch the value from OpenBao through the chosen pattern (sidecar injector, CSI provider or direct application call), and runs it in parallel with the existing Secret until behavior matches. The change is rolled out with a documented rollback path. The output is a migration runbook, a completed cutover record for that workload, and a short review of any failures or application changes it required.
Add dynamic database credentials
For workloads that connect to SQL databases, the team configures OpenBao's database secrets engine so each pod or application instance receives short-lived credentials with a lease instead of a shared password. Connection pooling and application retry behavior are tested, because credentials expire and must be renewed or reissued. The output is a configured database role per workload, lease settings agreed with the database owner, and evidence that an expired lease is refused by the database.
Remove static secrets and test rotation and revocation
Once each migrated workload runs without its static Secret for an agreed observation period, the team deletes the old Secret objects and removes any copies in manifests, Helm values or CI variables. Rotation is exercised on a sample of secrets, and a lease or bulk revocation is run in a test namespace to confirm access stops as expected. The output is a removal record, a rotation test report, and a revocation test report that the application owners accept.
Run backup and restore tests
The team takes a backup of OpenBao storage and of the etcd data that holds Kubernetes objects, then restores both into a separate environment and checks that secrets are readable with the expected unseal material. Kubernetes documents etcdctl snapshot save for backups and etcdutl for restores. The output is a restore test record with the steps, the people involved, the observed gaps and the fixes applied, plus a recovery runbook signed off by operations.
Evidence auditors ask for and which component produces it
This table maps the evidence an assessor typically asks for to the Kubernetes or OpenBao component that produces it and the HIPAA or FTC Safeguards control it supports. Use it to plan log retention and configuration snapshots before the assessment starts. Auditors and assessors decide whether any item is sufficient for their scope.
| Evidence item | Component that produces it | Control it supports |
|---|---|---|
| RBAC configuration and Secret access review | Kubernetes API audit logs and Role or RoleBinding objects exported on a schedule | HIPAA 164.312(a)(1) access control; FTC 314.4(c) monitoring of authorized user activity |
| Encryption at rest configuration for etcd | EncryptionConfiguration file and API server settings showing Secrets are encrypted before storage | HIPAA 164.312(a)(2)(iv) encryption; FTC 314.4(c) encryption at rest |
| OpenBao audit device logs for every secret read | OpenBao audit device output forwarded to the SIEM, with requests and responses logged in hashed form | HIPAA 164.312(b) audit controls; FTC 314.4(c) activity logging |
| Kubernetes auth role definitions per namespace | OpenBao Kubernetes auth roles that bind service accounts and namespaces to named policies | HIPAA 164.312(a)(1) unique user identification; FTC 314.4(c) least-privilege access |
| Lease and revocation records | OpenBao lease listings and revocation logs for dynamic database credentials | HIPAA 164.312(a)(1) access control; FTC 314.4(c) activity monitoring |
| Backup and restore test records for etcd and OpenBao storage | etcdctl snapshot save and etcdutl restore logs, plus OpenBao storage backup and restore runbook results | Availability and integrity expectations under HIPAA 164.312 and FTC 314.4 safeguards program |
| Pod Security Standards settings | Namespace labels enforcing a Pod Security Standards level, with admission controller logs | HIPAA 164.312(a)(1) access restriction; FTC 314.4(c) control of workload access |
Questions to ask an implementation partner before you commit
Start with the Secrets that already exist. Ask the partner how they will find Secrets already stored in etcd and in Git history, how they will rotate every credential that has been exposed there, and whether they will remove the old copies or only add OpenBao next to them. Kubernetes documentation states that Secrets are stored unencrypted in etcd by default and that anyone allowed to create a Pod in a namespace can read any Secret in it, so a partner who plans only to migrate values into OpenBao has not addressed the exposure. Ask for the encryption-at-rest configuration they will apply to the API server and what they will check after it is enabled. Then ask how Kubernetes auth roles are scoped. Each role should bind one service account, in one namespace, to the policies that workload needs, with the bound_service_account_names and bound_service_account_namespaces fields set explicitly. A wildcard here lets any workload in a namespace read another workload's secrets, so request the role list as a deliverable.
Ask which delivery pattern they recommend and why. The options are the Vault Agent injector, which runs a sidecar that writes secrets into the pod, the Secrets Store CSI Driver, which mounts secrets as files through a provider, and direct application calls to the OpenBao API. Each one changes where secrets land on disk, how rotation reaches the running process and how much logic sits in the application image. Ask how dynamic database credentials are leased and renewed, and what the application does when a lease is revoked. Next, ask where OpenBao will run. Ask whether it sits inside the cluster it serves or outside it, and what happens to pod secret delivery during a control plane outage if it runs inside. Ask how unseal and recovery keys are split, who holds each share, and where the auto-unseal key material is stored. Finally, ask how they test restores. Request a documented etcd snapshot restore using etcdctl snapshot save and etcdutl, and an OpenBao restore from storage, both run on a schedule and recorded as evidence. Also ask how OpenBao audit logs reach the SIEM, which fields are captured for each secret read, and whether the partner has verified that log delivery continues after a node failure.
Questions buyers ask before hiring help on Kubernetes secrets
What drives the effort and cost of moving Kubernetes secrets to OpenBao?
The main drivers are the number of namespaces, the number of workloads that read secrets, the number of databases that need dynamic credentials, the HA topology chosen for OpenBao, and whether an existing Vault estate has to be migrated. Each namespace adds auth roles and policies to design and test. Each workload adds a decision on how it receives secrets (injector sidecar, CSI driver or direct API calls) and a change to its deployment manifest. Dynamic database credentials add work on both the database and the application side. An HA cluster on integrated storage or PostgreSQL costs more to build and test than a single node used for a pilot. Ask any partner for a quote that lists these counts separately, so you can see which items move the total.
How long does a Kubernetes secrets project with OpenBao take?
The duration depends on the scope written into the agreement, so no fixed figure applies across environments. A narrow project that moves a handful of static secrets for one cluster and one team is much shorter than a project that covers several clusters, dynamic database credentials, certificate issuance and a migration from an existing Vault deployment. Timing also depends on your change windows, security review cycles and how quickly workload owners can test their applications against the new secret paths. DeployOpen plans most engagements as fixed-scope work, so the timeline is written down with the deliverables before work starts. Ask for milestones that separate platform build, workload onboarding and audit evidence.
What does the client need to provide for a Kubernetes secrets engagement?
Four inputs matter most. First, cluster administrator access, or a named administrator who can install the auth method, the injector or the CSI driver, and change API server encryption settings. Second, workload owners who can confirm which applications read which secrets and who will test changes in non-production namespaces. Third, database owners who can create the roles and grants that OpenBao uses to issue short-lived credentials. Fourth, a defined audit log destination, such as your SIEM, so that OpenBao audit events are retained and reviewed. Also expect to supply a backup target for OpenBao storage and a decision on who holds unseal and recovery material. Confirm these owners before the scope is signed.
Can our internal platform team run a Kubernetes secrets project alone?
A capable platform team can do much of this alone if it has time, Kubernetes and Linux operations skills, and someone who understands secrets lifecycle and audit requirements. The parts that most often stall internal projects are the first OpenBao deployment and its HA design, the Kubernetes auth role design across namespaces, and the migration of secrets that are scattered across manifests and CI variables. Unseal design and backup restore testing also need deliberate planning, because a mistake there affects every workload. Many teams split the work: internal staff own day-to-day operations and workload onboarding, while an implementation partner covers the design, hardening and documented runbooks. Decide which part your team will own after handover before you choose the split.
Can DeployOpen build OpenBao inside our own Kubernetes cluster?
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers and air-gapped networks. For Kubernetes secrets, that means OpenBao can run on the same cluster as the workloads, on a separate management cluster, or outside Kubernetes entirely, depending on your risk model and where the etcd and storage dependencies should sit. The right location is a design decision agreed during scoping, and it should be written into the statement of work. Ask any partner to show which topology they recommend for your cluster and why.
Which parts of a Kubernetes secrets setup are one-time and which recur?
The build is largely one-time work: designing the auth methods and policies, deploying OpenBao and its storage, configuring the injector or CSI approach, migrating existing secrets and writing runbooks. Recurring work covers OpenBao and Kubernetes upgrades, since Kubernetes minor releases are supported for a limited period and version skew rules govern the order of upgrades. It also covers rotation testing for dynamic and static secrets, backup and restore exercises, patching of the operating system and databases, and review of access policies as namespaces change. Ask for a quote that splits the fixed build from an ongoing support arrangement, and confirm which upgrades and test cycles are included.
Does Kubernetes secret encryption at rest solve the problem alone?
No. Kubernetes stores Secrets unencrypted in etcd by default, and encryption at rest is a recommended hardening step, but it does not limit who can read a secret through the API. Anyone allowed to create a Pod in a namespace can read any Secret in that namespace, so access depends on RBAC and workload design as well. Encryption at rest also leaves long-lived credentials in place, and secrets still need rotation and an audit trail. An external store such as OpenBao, reached through the Kubernetes auth method and an injector or CSI approach, changes who holds the secret and how access is logged. Plan both: encryption at rest and least-privilege RBAC for the cluster, and OpenBao for the secrets that need lifecycle control.
How DeployOpen scopes and builds Kubernetes secrets management
DeployOpen plans and implements self-hosted OpenBao inside your own cloud accounts, data centers or air-gapped networks, and wires it to your Kubernetes clusters. Each engagement starts with a written scope, so the auth methods, secret types and cluster layout are agreed before any work begins.
How we scope
- Inventory which workloads read Secrets today and which need dynamic database credentials or certificates.
- Record the cluster topology, namespaces, RBAC model and whether OpenBao runs on or off the cluster.
- Agree in writing which auth methods, injector or CSI patterns, storage backend and HA design are in scope.
How we build
- Deploy OpenBao with the chosen storage backend, unseal design and high availability layout in your environment.
- Configure the Kubernetes auth method, policies per namespace and service account, and secret paths.
- Test encryption at rest for etcd, least-privilege RBAC, lease revocation and failover before handover.
How we hand over
- Document architecture, policies, unseal and recovery procedures, and the backup and restore runbook.
- Deliver a tested backup and restore run, with results recorded against the agreed scope.
- Train platform and security staff to add namespaces, roles and secret paths without weakening policies.
How we support
- Offer ongoing support, upgrades and continuous testing through a retainer agreed separately from the build.
- Plan OpenBao version upgrades and Kubernetes upgrades so the two stay within supported version ranges.
- Review access policies and audit logs periodically and retest after significant cluster or policy changes.
