OpenBao Kubernetes secrets injection

How OpenBao Kubernetes secrets injection gets secrets into pods

OpenBao gets secrets into Kubernetes pods by having each pod authenticate with its own service account identity, then delivering the secret through either the Agent Injector or the CSI provider. The platform team needs this because applications need database and API credentials, and a static Kubernetes Secret is stored unencrypted in etcd unless encryption at rest is configured on the cluster. Keeping the credential in OpenBao means the cluster holds only a rendered file or a short-lived token, while the long-lived value stays in the secrets manager. Kubernetes auth in OpenBao binds a role to specific service account names and namespaces, and the policy attached to that role decides which secret paths a workload can read.

The login flow starts when the pod presents its projected service account token to the Kubernetes auth method. OpenBao validates that token against the Kubernetes API, checks it against the role's bound service accounts and namespaces, and returns a token scoped to the role's policies. With the Agent Injector, a mutating admission webhook adds an init container and a sidecar agent to pods that carry annotations, and the agent writes rendered secrets into a shared in-memory volume. With the CSI provider, the Secrets Store CSI Driver calls the provider at pod start and mounts the secrets as a volume. Confirm the exact injector and provider names, annotation keys and the CSI provider configuration against the OpenBao documentation for the release you deploy.

The choice between the two methods depends on how much pod mutation your admission policies allow and whether workloads already consume mounted volumes. The injector adds containers to every annotated pod, which increases the running footprint and changes the pod spec that your Pod Security Standards review sees. The CSI path mounts a volume and can be simpler for workloads that read files at startup, but you must confirm whether the provider version you deploy can also sync secrets into a Kubernetes Secret. If it can, that copy lands in etcd again, so the encryption and RBAC controls on Secrets become part of the design rather than an afterthought. Decide which method each workload class uses before writing any roles.

Before you build, confirm three things with OpenBao and Kubernetes documentation rather than assuming them. First, check that the Helm chart version and injector or provider release support your cluster's Kubernetes minor line, since the Kubernetes project currently maintains only the three most recent minor releases. Second, confirm the OpenBao release notes for the version you deploy, because the current line includes changes that affect auth and secrets handling. Third, restrict list and watch access on Secrets with least-privilege RBAC and check that no workload's service account can read another team's roles. Record the answers in your design document so your auditors can trace each secret from role to pod.

What you need before OpenBao can serve Kubernetes workloads

Both injection methods depend on the same foundation: a running OpenBao cluster that your Kubernetes clusters can reach and trust. Settle these six items before you choose between the Agent Injector and the CSI provider, because each one shapes how Kubernetes auth roles are configured. The exact Helm chart and sidecar requirements must be confirmed for the method you choose.

OpenBao cluster version

Choose the OpenBao release to run from the OpenBao releases page. The latest release in our reference set is v2.7.1, and v2.6.4 is the patch release for the previous minor line. Pick one version and record it, because the Helm chart, the injector or CSI provider, and the sidecar images must all be confirmed against that choice. Also confirm the storage backend and high availability design you plan to use, since those decisions are harder to change after secrets are loaded.

Supported Kubernetes minor line

Run on a Kubernetes minor line that is still maintained. As of September 2026, the project maintained 1.35, 1.36 and 1.37, with end-of-life dates of February 28, 2027, June 28, 2027 and October 28, 2027 respectively. Check the version skew policy for your cluster, since kube-apiserver must be upgraded one minor version at a time and kubelets may trail the API server by up to three minor versions. Plan any Kubernetes upgrade before it reaches end of life.

Network paths from the cluster

Map every path before deployment. Workload pods must reach the OpenBao API endpoint, the injector webhook must be reachable from the Kubernetes API server, and the injector or CSI components must reach OpenBao. Confirm firewall rules, egress policies, DNS resolution and any network policies that restrict traffic between namespaces. In a multi-cluster design, document each cluster's path separately, because a path that works from one cluster may be blocked from another.

TLS certificates and trust

Issue a certificate for the OpenBao endpoint that includes the names clients use, and make sure every pod, the injector and any CSI components trust the issuing CA. Decide who issues and rotates these certificates, and how a CA bundle reaches workloads without manual copying. Plan for certificate expiry before go-live, because a lapsed certificate blocks secret delivery across every namespace at once. Confirm the TLS settings the chosen chart expects.

API server address for token review

The OpenBao Kubernetes auth method verifies service account tokens by calling the cluster's API server, so OpenBao must be configured with an API server address it can reach and a CA certificate that validates it. Record the address your clusters expose, including any load balancer in front of the API server, and confirm OpenBao can reach it. Also decide which service account credential OpenBao uses for token review, and how it is rotated. Mismatched addresses are a common cause of failed logins.

Cluster and OpenBao admin accounts

Name the people or automation accounts that will hold each admin role. A cluster admin installs the chart, creates namespaces, service accounts and RBAC bindings, and manages the injector or CSI deployment. An OpenBao admin enables the Kubernetes auth method, writes the policies and creates the roles that map service accounts to secrets. Keep these duties separate where possible, store the initial OpenBao credentials under controlled access, and confirm the exact permissions each chart and method requires.

Choosing between the Agent Injector and the CSI provider

The two paths get the same secret to a pod through different machinery, and that difference shapes every later decision. With the Agent Injector, a webhook modifies annotated pods so that an init container and a sidecar run alongside the application. The sidecar authenticates to OpenBao, renders secrets from templates into a shared path inside the pod, and keeps them updated. With the CSI provider, the Secrets Store CSI Driver on each node calls the provider when a pod's volume is mounted, and the application reads the secrets as files in that volume.

Agent Injector: the pod gains extra containers, so its lifecycle, resource requests and startup order include the injected components.
CSI provider: the pod spec declares a CSI volume, so delivery depends on the volume attaching successfully.
Shared requirement: both paths authenticate through a Kubernetes auth role bound to a service account, so role design applies to either choice.
Failure surface: injection problems appear at pod admission or startup, while mount problems appear when the volume is attached.

Confirm each method's current limitations, supported Kubernetes versions and feature gaps in the OpenBao docs before you choose.

Setting up OpenBao Kubernetes secrets injection in order

This sequence connects Kubernetes service accounts to OpenBao so that each workload group receives only the secrets its policy allows, delivered by either the Agent Injector or the CSI provider. Each step ends with a check you can run, so a failure is traced to the step that caused it. Confirm exact configuration keys and component versions against the OpenBao and Kubernetes documentation for your release before you begin.

Confirm cluster and OpenBao prerequisites
Before changing OpenBao, confirm that the cluster API endpoint is reachable from the OpenBao servers, that you know which namespaces and service accounts will consume secrets, and that an administrator can create auth methods, policies and roles. The platform team usually owns the cluster side and the security team owns the OpenBao side, so agree in writing who makes each change. Confirm the OpenBao and Kubernetes versions against the support statements you plan to rely on. The step is done when a test pod in the cluster can open a connection to the OpenBao API address and your workload inventory is written down.
Enable the Kubernetes auth method
Enable the Kubernetes auth method at its default path or at a path your naming scheme defines, using an administrator identity. If you run several clusters, give each cluster its own mount so its configuration stays separate and is easy to review. The OpenBao auth methods documentation lists Kubernetes among the supported methods, so check the mount options for your release before you rely on them. The step is done when the auth method appears in the list of enabled methods at the expected path.
Configure cluster API address and token review
Set the cluster API address that OpenBao will use, and provide the token review settings described in the OpenBao auth methods documentation for the Kubernetes method. These settings decide how OpenBao confirms that a presented service account token is still valid, so the platform team should review the identity OpenBao uses for token review against least-privilege guidance. Supply the cluster certificate authority so the API connection is verified, and confirm the chain before saving. The check is a read of the saved configuration that shows the expected API address, the expected certificate and no placeholder values.
Create one policy and role per workload group
For each workload group, write one policy that grants read access only to the secret paths that group needs, then create a Kubernetes role that binds one named service account and one namespace to that policy. Avoid wildcard bindings for service accounts and namespaces, and keep one role per group so audit records map to a single workload. Name roles so that an auditor can match each role to its owning team. The check is a test login: a token from the named service account in the named namespace should authenticate and return a token carrying the expected policy.
Deploy the chosen delivery component
Install either the Agent Injector or the CSI provider, based on the delivery choice you made earlier, and point it at the OpenBao address and auth mount configured in the previous steps. Confirm the component's TLS trust settings, because a workload cannot receive secrets if the injector or provider does not trust the OpenBao certificate. Review the Pod Security Standards level applied to the namespace where the component runs and to the namespaces where workloads run. The step is done when the component pods report ready and the cluster shows the component's webhook or driver registered.
Annotate a test workload and confirm delivery
Create a test namespace and a test service account that matches one of the roles from the earlier step, then deploy a test pod with the annotations or volume configuration the chosen component requires. Use a disposable test secret that holds no real credentials. The check is a rendered file or mounted secret inside the test pod at the expected path, with a value that matches the test secret. If the pod stays pending or the file is missing, review the component logs and the OpenBao audit log for the login attempt before changing any role.
Verify access boundaries with denied reads
Run negative tests before any production workload uses the setup. From a pod in a different namespace, or using a service account that is not bound to the role, attempt the same login and secret read, and confirm both are refused. Check that each refused attempt appears in the audit log with the expected identity. Store the test definitions and results alongside the role documentation so the security team can repeat the tests after upgrades or role changes. The step is complete when every denied case is refused and every allowed case succeeds.

How Kubernetes auth roles tie each service account to its secrets

The security boundary in OpenBao's Kubernetes auth method is the role, not the pod. When a workload presents its service account token, OpenBao asks the Kubernetes API to confirm that token, then matches the service account name and namespace against the bound values on a role. Whatever that role grants is what the workload can read. Before you write any policy, decide which roles exist, which service accounts each one binds to, and which policies each role attaches. Treat the role map as an access control list that you review like any other. One role per service account is the pattern to start from. Each application gets its own service account, its own OpenBao role bound to exactly that name and namespace, and a policy that covers only the secret paths that application needs. If two workloads need the same secret, give them separate roles that reference a shared policy, so you can still revoke one without touching the other. Illustrative example: a payments API role bound to the service account payments-api in the payments namespace, attached to a policy that reads only the payments/api path. Confirm the exact bound-field names and their matching behavior in the Kubernetes auth documentation for your OpenBao release before you script them. Wildcard bindings are the most common way this model quietly widens. A binding that accepts any service account in a namespace, or a wildcard across namespaces, means that any future workload you deploy into that namespace inherits the role's secrets without review. A compromised low-value pod in that namespace can then request the same secrets as the sensitive service. Use explicit names and namespaces, and make a wildcard an exception that needs a written reason. Review existing roles for wildcards as part of your first audit, because they often arrive through copied examples. Token lifetime and policy paths decide what a compromised pod can read after the attack starts. A token issued at login is valid for its time-to-live and can be renewed up to a maximum, so short lifetimes and bounded maximums shorten the window in which a stolen token is useful. Set these values per role rather than relying on instance-wide defaults, and confirm the default TTL and maximum TTL behavior in the auth docs for your release before you depend on them. Policy paths matter just as much: a path ending in a wildcard exposes everything beneath it, so write policies against the narrowest path that works and avoid broad capabilities such as list on parent paths. Before go-live, run a short exercise. For each role, record the bound service account, namespace, token settings, attached policies and the paths those policies allow. Then use a test pod in a non-production namespace to confirm that it can read only its own paths and that a token from a neighboring service account is refused. Schedule this review whenever a namespace or service account is created, and ask your partner or internal team to include role bindings in the same change review as application manifests.

Mapping namespaces, service accounts and policies to secret paths

This table traces each link from a Kubernetes namespace to a secret path, so every grant can be followed from workload to data. Read it left to right for one workload, using the illustrative payments example as a pattern. The main takeaway is that each role should bind one namespace and one service account, and its policy should grant read access only to the paths that workload uses.

Element	What to decide	Illustrative payments example	Check at review
Kubernetes namespace	Name the single namespace where the workload runs	payments-prod	Confirm no other team deploys workloads into this namespace
Service account	One dedicated account per workload, never the namespace default	payments-api, used only by the API deployment	Confirm no other pods use it and token automount is set on purpose
OpenBao role	Kubernetes auth role bound to one service account and one namespace	payments-api role bound to payments-prod and payments-api	Confirm the bound namespace and account still match the workload
Bound policy	Least-privilege policy granting read on named paths only	payments-read policy with read on one KV v2 path	Confirm no list, write or wildcard capabilities were added
Secret path	The exact path the policy grants, scoped to this workload's data	kv/data/payments/prod/card-gateway	Confirm the path holds only secrets this workload needs
Delivery method	Agent Injector or CSI provider, chosen per workload	Agent Injector writes the secret to a file inside the pod	Confirm the method matches how the application loads secrets
Owner and review date	A named owner and a scheduled review for every row	Payments platform lead, reviewed on a fixed calendar date	Confirm the owner is still in role and the review date is booked
Tenant isolation	Consider OpenBao namespaces where tenants share one cluster	Separate OpenBao namespace for each tenant that shares the cluster	Confirm tenants cannot see each other's roles, policies or paths

Hardening secret delivery so pods get only what they need

Delivering secrets into Kubernetes is only as safe as the policies, roles and cluster settings around it. The controls below cover both sides of the path: what OpenBao will release to each workload, and what Kubernetes will let a workload see once the secret arrives.

Least-privilege policies per role

Write one OpenBao policy for each Kubernetes auth role, scoped to the exact secret paths and capabilities that workload needs. Avoid wildcard paths and broad list permissions, because a compromised pod can only read what its role allows. Review each policy against the application's actual reads before go-live, and confirm that a role bound to one namespace and service account cannot be used from another.

Controlling who changes roles

The Kubernetes auth roles that map service accounts to policies are the main lever for access, so changes to them need the strongest protection. Restrict the OpenBao tokens and policies that can create or update roles to a small platform group, and route changes through version-controlled review. Confirm that application teams can request a role but cannot widen their own binding.

Namespaces for tenant isolation

OpenBao supports namespaces within one cluster, which can separate policies, auth mounts and secrets engines for different tenants or business units. Decide early whether a shared cluster needs this boundary or whether separate clusters better match your risk model. If namespaces are used, confirm that administrators of one namespace cannot read or alter another's roles.

Pod Security Standards for injector components

The Agent Injector or CSI provider runs with elevated visibility into pods and mounted secrets, so its namespace needs deliberate pod security settings. Review the enforcement level applied to the namespace against the Kubernetes Pod Security Standards, and document any exceptions the chosen injector or provider requires. Confirm the exact privileges the components request before accepting them as exceptions.

RBAC that blocks reading delivered Secrets

Injection can be bypassed if workloads can read the Kubernetes Secret objects that hold the same values. Limit get, list and watch on Secrets to the components that need them, and confirm that application service accounts cannot read Secrets in their own or other namespaces. Test this with a service account impersonation check rather than assuming the default bindings are correct.

Encryption at rest for remaining Secrets

Any Kubernetes Secret that still exists, such as bootstrap credentials or certificates created by other tools, is stored unencrypted in etcd unless encryption at rest is configured. Enable an encryption configuration on the API server, confirm that existing objects are re-encrypted, and check that etcd backups inherit the same protection. Ask your platform team to show the active encryption provider before sign-off.

Audit logging for OpenBao reads

Every secret read by a pod should leave a record that can be tied to a role, namespace and time. Enable the OpenBao audit device, send its output to a log store that the platform team cannot silently edit, and alert on unexpected reads from roles or paths outside their normal pattern. Confirm that audit entries are sensitive-value-hashed or redacted as your policy requires.

How to test OpenBao Kubernetes secrets injection before production traffic depends on it

The test plan has to prove three things before any production namespace depends on injection: the intended workload receives the intended secret, every other identity is refused, and the secret keeps working through change. Start in a canary namespace that mirrors production labels, admission policies and network rules. Give it a dedicated test service account and one Kubernetes auth role bound only to that account and namespace. Store the test value under a throwaway path so a failed experiment cannot expose production data. Record the OpenBao version, the injection method (Agent Injector or CSI provider) and the Kubernetes version under test, because a passing run tells you little once any of those change.

Positive and negative cases carry most of the weight. The positive case: a pod running as the canary service account reads the test secret, and the delivered file has the expected path, owner, permissions and content. The negative cases: a pod in the same namespace under a different service account is denied, a pod in another namespace using a same-named service account is denied, and a correct identity without the right policy cannot read adjacent paths. Also review the role's bound namespace and service account fields. A wildcard binding can pass the positive case and fail only when someone else deploys into the namespace later. Confirm that each denial appears in the audit device with the expected identity, so the negative results are recorded rather than assumed.

Rotation and restart tests show what happens after the first read. Change the value in OpenBao and confirm the pod receives the new value within the interval your design allows. Confirm whether the application reloads it, or document that it requires a restart. Let a short-lived lease expire in the test to see how renewal and re-authentication behave. Then restart the workload and confirm it authenticates again and receives the secret without manual steps. A restart during an OpenBao outage is the case most likely to fail in production, so include that scenario. Also check that no Kubernetes Secret object is created as a side effect unless you chose that design, since Secrets are stored unencrypted in etcd by default unless encryption at rest is configured.

If OpenBao runs in high availability, test failover on the storage backend you actually operate. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends. While a test workload reads the secret in a loop, stop the active node and record how many reads fail and for how long. Confirm that a standby takes over and that injection resumes without redeploying workloads. Repeat with a standby restart. Any timing or throughput figures should come from your own measurements in your environment, since vendor material and this page do not replace them, and the canary results become the baseline for capacity planning. Keep configurations, command output, dates and versions in an evidence folder mapped to each test case. This supports audit preparation. It does not amount to a certification or an audit report, so ask your assessor which evidence they expect.

Common OpenBao Kubernetes secrets injection failures and fixes

This table matches common symptoms of OpenBao secrets injection in Kubernetes to their likely causes and fixes. Find the symptom in pod events or OpenBao logs, then work through the cause and fix. Confirm the exact error text against the OpenBao logs for your version before changing configuration, because message wording varies by release. Most failures come from identity binding, network reachability or trust, so check those first.

Symptom	Likely cause	Fix
Login denied with permission error on the Kubernetes auth login path	The auth role binds a different service account name or namespace than the pod actually uses	Set the bound service account and bound namespace on the role to match the pod spec exactly, then retest the login
Token review fails during Kubernetes login	The auth method points at the wrong API server address, or the reviewer service account lacks permission to create token reviews	Correct the API server address in the auth configuration and grant the reviewer account token review permissions
Pod stays in Init state and the sidecar never completes	The injector or sidecar cannot reach the OpenBao address because of DNS, egress rules or a network policy	Confirm the address in the pod annotations, test connectivity from the pod namespace, and allow egress to the OpenBao port
TLS errors such as unknown certificate authority in sidecar or injector logs	The CA that signed the OpenBao listener certificate is missing from the trust bundle used by the injector or sidecar	Supply the CA bundle to the injector and auth configuration, and confirm the certificate names match the address in use
Application keeps old secret values after rotation	The workload reads a rendered file once, or a cached token or lease keeps returning the previous credential	Check the template refresh interval, confirm the lease TTL and renewal behavior, and reload the workload as your design requires
Pods fail to create and the injector webhook is absent	Pod Security Admission on the namespace enforces a level that blocks the injector's pod settings	Confirm the level the injector chart requires, then label the namespace at a level that permits it or scope an exemption

Questions teams ask before running OpenBao Kubernetes secrets injection

How much does OpenBao Kubernetes secrets injection cost?

The cost comes from the scope of the work, and the written scope document is the source for any figure. OpenBao is licensed under MPL-2.0, so the software itself carries no license fee. The cost drivers are:

Cluster count: each cluster needs its own auth configuration and testing.
Workloads and roles: each service account role needs design, review and testing.
HA design: the storage backend and failover model change the build.
Existing secret stores: any current source you reconcile with OpenBao adds work.
Migration from Kubernetes Secrets: inventory, cutover and rollback take effort.
Compliance evidence needs: the records your assessors expect shape the build.

Design, build and cutover are one-time costs. Your staff time, infrastructure, and any retainer for upgrades and support recur. Ask for a quote that itemizes each component.

How long does an OpenBao Kubernetes secrets injection project take?

Duration follows the same drivers as cost, and the written scope document states the timeline for your environment. The largest variables are the number of clusters, the number of workloads needing roles, and whether you migrate existing Kubernetes Secrets in the same phase. Other factors that extend the schedule include:

Change windows: production cutovers often run only in approved periods.
Review cycles: role and policy reviews depend on your security reviewers' availability.
Owner decisions: each workload needs a named owner who confirms its secret paths and access needs.
Test cluster availability: validation needs a cluster that matches production closely enough to trust the results.

Ask for the timeline as milestones tied to these items, so you can see which decisions move the date.

What must our team provide before an OpenBao injection engagement starts?

Your team must provide access, ownership and decisions before design starts. The required inputs are:

Cluster access: working credentials for a test cluster and each production cluster in scope.
Owners for each workload: a named person who confirms the secrets, namespaces and service accounts that each workload uses.
Delivery method decision: a choice between the Agent Injector and the CSI provider for each workload group.
Change windows: approved times for rollout, cutover and rollback on each cluster.
Security reviewer: someone who can approve Kubernetes auth role and policy design.
OpenBao location: confirmation of where the OpenBao cluster runs and who operates it.

Missing owners and undecided delivery methods cause most of the rework, so confirm them in writing before the scope is signed.

Can our internal platform team set up OpenBao injection on its own?

Yes, an internal team can set up a first working injection using the OpenBao and Kubernetes documentation and a test cluster. A single workload with one role is a reasonable first exercise for that purpose. The usual gap appears when the team scales the pattern. Role design is where most teams struggle: each Kubernetes auth role should map to a specific service account and namespace, with policies limited to the paths that workload needs. Independent review of those roles, and testing of denied access as well as allowed access, are the steps teams most often skip. Plan for a second reviewer on role and policy changes, and decide who owns those reviews after go-live.

Does DeployOpen deliver this work as fixed-scope with a written quote?

Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. Ask the quote to state:

Deliverables: the clusters, workloads, roles and documentation included.
Acceptance tests: how each injection path is verified before handover.
Exclusions: items outside the scope, such as applications you change yourself.
Assumptions: the access, owners and change windows the timeline depends on.
Change process: how scope changes are priced and approved during the work.

Ongoing support, upgrades and continuous testing are available as retainers and can be quoted separately from the build.

Does OpenBao or DeployOpen certify our Kubernetes secrets setup for compliance?

No. Neither OpenBao nor DeployOpen issues certifications, attestations or audit reports for this setup. DeployOpen prepares systems, controls and evidence for compliance assessments, such as role definitions, access reviews and audit log records. Independent auditors and certification bodies assess that evidence and decide the outcome. Before the build, confirm with your assessor which evidence they expect for secret access, rotation and logging, and which control frameworks apply to your organization. Those requirements should appear in the written scope so the evidence is collected during the work rather than reconstructed afterward.

Should we choose the Agent Injector or the CSI provider for OpenBao?

Choose by workload, using the trade-offs below, and confirm each behavior against the documentation for your OpenBao and Kubernetes versions. The Agent Injector runs alongside each pod and writes secrets to the pod's filesystem, which suits applications that read files and need templating. The CSI provider works through the Secrets Store CSI Driver and mounts secrets as volumes, which suits teams already standardizing on that driver. Check two points before deciding:

Native Secret objects: confirm whether either method can sync values into Kubernetes Secret objects, since those are stored unencrypted in etcd by default unless encryption at rest is configured.
Lifecycle and rotation: confirm how each method handles renewal, rotation and pod restarts for your workloads.

Record the decision per workload group so the role design matches the chosen method.

How DeployOpen scopes and delivers this integration

DeployOpen plans, implements, documents and supports OpenBao Kubernetes secrets injection inside your own clusters and cloud accounts, so the secrets path stays under your control. Each engagement starts from a written, fixed scope that names the injection method, the Kubernetes auth roles and the workloads in scope. The work is delivered and handed over as documented, supportable configuration that your platform team can run.

How we scope

The written scope names the injection method, Agent Injector or CSI provider, and why.
Scope lists each workload, its service account and the OpenBao secret paths it may read.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Confirm the OpenBao cluster, Kubernetes distribution and identity source before any injection work starts.
Configure Kubernetes auth roles per service account, bound to namespaces and least-privilege policies.
Test that each pod receives only its own secrets, and that denied paths fail as designed.

How we hand over

Documentation covers the role-to-workload map, policy files, injector or CSI configuration and rollback steps.
Your platform team walks through the configuration and runs the verification checks themselves.
Handover includes a list of open items, owners and recommended checks for future Kubernetes upgrades.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover OpenBao and Kubernetes version changes that affect injector or CSI behavior.
Security testing of workloads and auth roles can be added to a retainer if the scope includes it.