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.
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
| 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
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
- 01Open
Cluster baseline
Choose the profile, bootstrap path, and server defaults that define how the cluster starts and what posture it can realistically sustain.
- 02Open
Service boundary
Define how traffic reaches OpenBao, where TLS terminates, and which network assumptions the workload is allowed to make.
- 03Open
Platform readiness
Finish storage, observability, and registry decisions before the cluster becomes expensive to move or hard to inspect.
Continue cluster shaping
This version tracks a prerelease build. Features and behavior may change before the next stable release.
Was this page helpful?
Use Needs work to open a structured GitHub issue for this page. The Yes button only acknowledges the signal locally.