Roadmap

OpenBao Operator is built around a lifecycle core with optional modules for self-service, fleet management, federation, and application integration.

Roadmap status

This roadmap describes the current project direction. It is not a commitment to release dates, final feature scope, or delivery order. Priorities may change based on implementation findings, user feedback, security review, and maintainer capacity.

Direction

OpenBao Operator starts from one primary responsibility: operate OpenBao safely on Kubernetes.

The core lifecycle layer owns deployment, TLS, initialization, unseal configuration, backups, restores, upgrades, read scaling, tenant onboarding, production posture checks, admission guardrails, and status reporting. Future modules build on that lifecycle contract instead of replacing it.

The design principle is:

Core owns lifecycle. Modules express intent. Modules do not bypass the lifecycle contract.

Current focus

Claims and Service Offerings are the next visible product direction. They turn OpenBaoCluster into a platform-defined offering that tenants can request through a smaller claim API.

The same-cluster Claims and Service Offerings path is in integration. See the Claims and Service Offerings design note for the current public design shape and supported boundaries.

Application integration, multi-cluster management, federation, and SPIFFE/SPIRE remain planned directions while their API boundaries, security model, and operating contracts are refined.

Upstream OpenBao alignment

OpenBao Operator should track upstream OpenBao direction and adopt new OpenBao capabilities when they strengthen the operator lifecycle contract or a planned module. Integration still depends on stable upstream behavior, documented APIs, security review, and a clear Kubernetes operating model.

Relevant upstream areas include OpenBao scalability, namespace and tenancy features, policy and auth improvements, plugin distribution, backup and restore capabilities, read scaling, and future replication or data-placement features if they become available in OpenBao.

This does not mean every upstream feature becomes an operator feature. The operator should expose upstream capabilities when it can preserve clear ownership, status reporting, upgrade safety, and blast-radius boundaries.

Capability map

Reference table

Roadmap areas

Roadmap areas.

Area	Public status	Direction
Core lifecycle	Available	Secure OpenBao cluster lifecycle management on Kubernetes.
Claims and Service Offerings	In progress	Self-service OpenBao clusters through platform-defined offerings and smaller tenant-facing claims.
Application integration	Planned	Explicit workload access patterns using Kubernetes identity, CSI, Agent or Proxy delivery, and opt-in Secret sync.
Multi-cluster management	Planned	A management-plane model with downstream agents that reconcile close to workload clusters.
Federation	Planned	Central governance for policy, auth, PKI, and secret-engine configuration while keeping execution local.
SPIFFE/SPIRE integration	Exploring	Optional identity integration for environments that already operate SPIFFE/SPIRE.

Core lifecycle foundation

The core lifecycle API is an operator-owned contract for clusters the operator creates and reconciles. It is not a generic import API for arbitrary unmanaged OpenBao clusters.

Core lifecycle responsibilities include:

• OpenBao cluster deployment
• TLS configuration
• initialization and self-initialization flows
• external or OpenBao-native unseal configuration
• backup and restore workflows
• upgrade orchestration
• read scaling
• tenant onboarding
• production posture checks
• admission and configuration guardrails
• status and condition reporting

Claims and Service Offerings

Claims and Service Offerings add a self-service layer above OpenBaoCluster.

Platform operators define approved cluster shapes as offerings. Tenant or application teams request instances through a smaller claim API. The claim should expose the decisions a tenant needs to make, while platform policy, defaults, guardrails, and lifecycle rendering stay inside the offering.

Direction:

• keep the claim API small and user-focused
• keep platform policy inside Service Offerings
• track which offering revision rendered a claim
• support safe claim behavior when offerings change
• project useful status from the rendered OpenBaoCluster back to the claim
• avoid exposing raw lifecycle internals unless the offering explicitly allows it

Application integration

Application integration covers how workloads consume secrets from OpenBao.

The preferred direction is identity-first and explicit. The operator should reconcile access relationships, policies, auth roles, and delivery configuration. It should not silently mutate application Pods as the default integration mechanism.

Potential integration paths include direct client access, CSI volume delivery, Agent or Proxy delivery, compatibility-focused Kubernetes Secret sync, and SPIFFE/SPIRE auth for environments that already operate it.

Direction:

• avoid mutating workload webhooks as the default path
• avoid Kubernetes Secrets by default
• use short-lived workload identity
• make delivery mode explicit
• keep secret values out of CRDs, status, logs, and events
• support Kubernetes ServiceAccount identity as the default
• support SPIFFE/SPIRE as an advanced identity backend

Multi-cluster management

Multi-cluster management is intended to let a management control plane operate OpenBao clusters on downstream workload clusters.

The preferred direction is a hub-and-agent model. The management plane expresses placement and fleet intent. A downstream agent runs near each workload cluster and reconciles local resources with local permissions.

Direction:

• avoid storing broad kubeconfigs for downstream clusters in the management cluster
• prefer outbound connectivity from downstream clusters where possible
• keep local Kubernetes RBAC local
• support per-cluster identity and revocation
• propagate status back to the management plane
• allow claims to target placements instead of individual clusters
• support operator-managed mTLS as the default identity mode
• support SPIFFE/SPIRE as an advanced identity mode

Federation

Federation provides central governance for multiple OpenBao clusters.

Federation does not mean stretching one OpenBao storage cluster across multiple workload clusters. It also does not make tokens, leases, or root credentials portable between clusters.

The preferred model is federated control with local execution. A management OpenBao cluster and federation controller can define shared intent, while downstream OpenBao clusters continue to serve local workloads, issue local leases, keep local audit trails, and enforce local auth.

Potential federation areas include policies, auth methods, auth roles, secret engines, dynamic secret roles, PKI, and explicitly scoped static secret export. Tokens, leases, and root credentials are not federation targets.

Direction:

• keep downstream OpenBao clusters independently operable
• keep leases local to the cluster that issued them
• keep application authentication local wherever possible
• make static secret export explicit and narrow
• prefer policy, auth, PKI, and secret-engine federation before secret-value federation
• support drift detection
• support safe deletion and conflict policies
• preserve clear blast-radius boundaries

SPIFFE/SPIRE integration

SPIFFE/SPIRE is planned as an optional advanced identity integration. It should not be required for normal OpenBao Operator usage.

SPIFFE/SPIRE may support:

• downstream agent identity in multi-cluster management
• federation hub-to-agent trust
• workload identity for application access
• OpenBao cert-auth or JWT-auth integrations
• trust-domain-aware policy and access binding models

Default users should be able to use Kubernetes ServiceAccount identity without installing SPIRE. Environments with existing SPIFFE/SPIRE deployments should be able to use SPIFFE identities as first-class subjects.

Longer-term exploration

The following areas are candidates for future work. They are intentionally listed as exploration, not committed scope, and remain bounded by the non-goals below.

Visibility and governance

• access graph and who can read what explanations
• secret consumption inventory across workloads
• reusable policy packs and policy impact simulation
• compliance evidence export

Reliability and fleet operations

• restore drills and backup confidence checks
• federation drift detection and reconciliation modes
• fleet-aware progressive rollout strategies
• cluster capability discovery for placement decisions

Platform ecosystem

• OpenBao PKI platform capabilities
• developer portal, GitOps, Crossplane, Terraform, OpenTofu, and CLI integrations

Non-goals

The following are not current roadmap goals:

• transparent OpenBao storage replication across independent clusters
• making OpenBao tokens portable between clusters
• replicating leases between clusters
• automatically copying all secrets from a management cluster to downstream clusters
• making SPIFFE/SPIRE mandatory
• using mutating workload webhooks as the default application integration path
• turning OpenBaoCluster into a generic import API for unmanaged OpenBao clusters
• giving the management plane unrestricted root access to all downstream clusters by default

Principles

The roadmap is guided by these principles:

1. Secure defaults first. Prefer explicit identity, least privilege, short-lived credentials, and safe failure modes.
2. Core lifecycle remains separate. Modules build on the lifecycle contract instead of bypassing or duplicating it.
3. Modular adoption. Users can adopt self-service, multi-cluster, federation, application integration, and SPIFFE support independently.
4. No hidden secret movement. Secret values do not move between systems unless a user explicitly configures that behavior.
5. Status over surprise. External dependencies, missing prerequisites, degraded integrations, and unsafe configurations surface through status conditions.
6. Local ownership where it matters. Downstream OpenBao clusters retain local authentication, local lease ownership, local auditability, and local recovery options.
7. Advanced features stay explicit. SPIFFE/SPIRE, federation, secret export, and multi-cluster management do not become hidden requirements for basic OpenBao operation.

Feedback

The roadmap will evolve through implementation work, user feedback, and security review.

Feedback is welcome through GitHub issues and discussions, especially around self-service claim workflows, platform offering design, multi-cluster operating models, federation use cases, application integration patterns, SPIFFE/SPIRE expectations, and security boundaries.

Related sections

Operator invariantsLifecycle contracts and safety properties that future modules must preserve.Known limitationsCurrent constraints and explicit non-goals for the pre-GA release line.Support policyCurrent release support posture and pre-GA maintenance expectations.