Read OpenBaoCluster as the contract for the whole service, not just a CRD.

OpenBaoCluster is the declarative contract for the running OpenBao service on Kubernetes. It sets the cluster shape, service boundary, storage path, and day 2 capabilities the operator will keep reconciling. Use this page to orient the rest of Configure before you start editing individual fields.

A good read of this page should leave you with

• a clear view of what the operator owns versus what the platform still expects from you
• the right mental model for spec as desired state and status as the observed operating surface
• a shorter list of pages to read next instead of a flat wall of configuration topics
• the confidence to shape the first cluster without treating the CR as an arbitrary field dump

Profile is an explicit part of the contract

Set spec.profile deliberately. Hardened and Development are not stylistic presets; they change the security posture, bootstrap requirements, and what the operator will allow the cluster to do.

Decision matrix

What OpenBaoCluster is responsible for

What OpenBaoCluster is responsible for.

Area	What the spec controls	What still belongs to you
Cluster shape	Version, replica count, security profile, bootstrap path, and the baseline runtime configuration the operator should keep in sync.	Choose values that match the environment and failure model you actually intend to run.
Service boundary	Services, Gateway or Ingress integration, and cluster network configuration.	Own the edge design, DNS, certificate authority, and network assumptions outside the cluster itself.
Platform readiness	Storage size, workload requests, telemetry enablement, and mirrored-image defaults that affect runtime behavior.	Provide the correct StorageClass, registry access, monitoring stack, and cluster capacity around the workload.
Day 2 workflow hooks	Backup scheduling, restore auth bootstrap, upgrade strategy, maintenance mode, and pause behavior.	Actually operate those flows: verify backups, plan upgrades, and respond to recovery conditions as part of the service lifecycle.

Diagram

GitOps contract

The spec is the desired cluster shape. The operator renders and maintains the Kubernetes workload, then reports the observed operating state back on status.

Configure

Recognize the major spec surfaces in one manifest

yaml

apiVersion: openbao.org/v1alpha1
kind: OpenBaoCluster
metadata:
name: prod-cluster
namespace: openbao
spec:
version: "2.5.0"
profile: Hardened
replicas: 3

storage:
  size: "50Gi"
  storageClassName: "fast-ssd"

selfInit:
  enabled: true
  oidc:
    enabled: true

service:
  type: ClusterIP

observability:
  metrics:
    enabled: true

backup:
  schedule: "0 3 * * *"

The point is not to memorize every field. It is to see the major configuration surfaces that map to the rest of the section: baseline, service boundary, platform readiness, and day 2 operations.

Read Configure in layers

1. 01

   Cluster baseline

   Choose the profile, bootstrap path, and server defaults that define how the cluster starts and what posture it can realistically sustain.

   Open
2. 02

   Service boundary

   Define how traffic reaches OpenBao, where TLS terminates, and which network assumptions the workload is allowed to make.

   Open
3. 03

   Platform readiness

   Finish storage, observability, and registry decisions before the cluster becomes expensive to move or hard to inspect.

   Open

Continue cluster shaping

Security profilesStart with the production posture and bootstrap model before you spend time on edge or observability details.External accessMove to the service boundary once the baseline cluster shape is clear.Prepare for day 2Return to the operating path once configuration choices are explicit enough to support upgrades, backups, and recovery.