0.4.0

0.4.0

Published 2026-07-04.

Matching docs

Open the docs experience aligned to this release line.

OpenGitHub release

View release assets, tag metadata, and the GitHub release entry.

Open

0.4.0 is the next stable pre-GA release line for OpenBao Operator. This release focuses on security-boundary hardening, explicit delegation for high-impact controls, and safer self-initialization for auto-unseal clusters. It also refreshes the OpenBao validation baseline and expands property and model-based test coverage for lifecycle-critical paths.

Highlights

• Tightened the authorization boundary around sensitive OpenBaoCluster and OpenBaoRestore controls. Network publication, custom helper images, image trust roots, cloud identity references, restore delegation, and other high-impact fields now require explicit Kubernetes-side authority instead of being implicitly accepted from ordinary cluster update rights.
• Hardened the production contract for unsafe controls. Hardened clusters now reject more ambiguous or unsafe shapes consistently, including raw or broad network policy escape hatches, implicit object-storage identity in hardened backup and restore paths, unsafe TLS and observability settings, and dangerous runtime overrides.
• Added managed-resource provenance guardrails. Operator-managed resources are annotated with ownership metadata, and admission policies lock protected resources so direct mutation does not silently bypass the owning OpenBaoCluster contract.
• Added initial recovery-key bootstrap for self-initializing auto-unseal clusters through spec.recoveryKeys.initial. The operator can now render the first recovery-key request with declared OpenPGP recipients, share count, and threshold during initial self-init.
• Made self-init bootstrap configuration one-shot. Bootstrap configuration is cleaned up after initialization succeeds, reducing the chance that stale first-boot material remains part of steady state.
• Moved the default OpenBao validation baseline to 2.5.5, with current release validation covering Kubernetes v1.34 and v1.35 and config compatibility coverage for OpenBao 2.4.4 and 2.5.5.
• Refreshed Go, base image, GitHub Actions, website, and transitive dependency baselines, including the dependency security-policy alignment needed by CI and Nightly security scans.
• Added property and model-based tests for ownership/provenance, backup job environment rendering, operation locks, upgrade request state, rolling upgrade state, and restore lifecycle behavior.

Breaking and Migration Notes

• Apply the 0.4.0 CRDs before upgrading the controller or Helm chart. This release adds and tightens openbao.org/v1alpha1 fields, validation rules, admission policies, and delegated RBAC roles.
• Review RBAC for every identity that creates or updates OpenBaoCluster and OpenBaoRestore resources. Users, GitOps controllers, and platform automation may now need explicit delegated roles for network publication, helper images, image trust roots, cloud identity references, restore delegation, custom executables, or other dangerous controls.
• Review existing Hardened clusters before applying admission enforcement. Specs that previously updated successfully may now be rejected if they rely on unsafe controls, broad network rules, provider-default backup or restore identity, TLS verification bypasses, backend HTTP, raw ingress rules, or dangerous runtime flags.
• Review direct mutations of operator-managed Kubernetes resources. Resources owned by an OpenBaoCluster are now expected to carry operator provenance, and protected managed resources should be changed through the owning custom resource rather than patched directly.
• For self-init clusters, configure a real human access path in spec.selfInit.requests before first reconcile. spec.selfInit.oidc.enabled only bootstraps operator lifecycle authentication; it does not create user login access after the root token is auto-revoked.
• Use spec.recoveryKeys.initial only for first-time self-initialization on non-static unseal clusters. The recipient count must match the share count, the threshold must be valid, and OpenPGP key custody and proof ceremonies remain user-owned processes.

Operational Notes

• Treat 0.4.0 as a security-hardening release when planning rollout. Stage the CRD and admission-policy update, then validate representative cluster specs before upgrading production controllers.
• In multi-tenant environments, audit the difference between ordinary cluster authors and platform administrators. The new delegated roles are intended to let tenants manage day-to-day cluster intent without automatically gaining authority over publication, restore, image, or identity trust boundaries.
• If you use GitOps, make sure the controller identity has the same delegated permissions as the human or platform role it represents. Otherwise GitOps may fail on apply even when the manifest is otherwise valid.
• If you rely on backup, restore, or upgrade jobs, verify the JWT role path and object-storage identity path in staging. Hardened clusters favor explicit job identity through credentialsSecretRef, workload identity metadata, or provider-specific role configuration instead of ambient credentials.
• Self-init recovery-key bootstrap does not replace recovery-key custody. Plan recipient verification, share distribution, and recovery proof outside the operator workflow.
• Users already running 0.3.x have the 0.3 hardening around inline auth, metrics, audit file storage, Gateway/Ingress readiness, PKCS#11 runtime wiring, backup and restore validation, and storage endpoint guards; those remain included in 0.4.0.

Upgrade from 0.3.x

Before upgrading an existing 0.3.x installation:

1. Review every existing OpenBaoCluster and OpenBaoRestore against the new delegated authorization and Hardened validation rules.

2. Grant only the required delegated RBAC roles to the identities that need network publication, restore, helper image, trust root, cloud identity, or custom executable authority.

3. For Hardened clusters, replace broad or implicit configuration with explicit ingress peers, port-scoped egress rules, non-static unseal, trusted TLS, and explicit backup/restore identity.

4. For self-init clusters, confirm spec.selfInit.requests creates a user login path before root token revocation, and add spec.recoveryKeys.initial only before the first initialization event.

5. Apply the 0.4.0 CRDs first:

   kubectl apply -f https://github.com/dc-tec/openbao-operator/releases/download/0.4.0/crds.yaml

6. Upgrade the Helm release:

   helm upgrade openbao-operator oci://ghcr.io/dc-tec/charts/openbao-operator \
     --version 0.4.0 \
     --namespace openbao-operator-system \
     --reuse-values

7. Verify admission-policy health, delegated RBAC coverage, operator rollout, managed cluster conditions, backup/restore events, and recent controller logs before continuing with production workload changes.

Compatibility

OpenBao Operator requires Kubernetes v1.33+. The current release validation baseline is Kubernetes v1.34-v1.35 and OpenBao 2.5.5, with config compatibility coverage for OpenBao 2.4.4 and 2.5.5.

Features

• security: require authority for network publication (#507) (f873094)
• self-init: add initial recovery key bootstrap (#516) (a04cb23)

Bug Fixes

• security: delegate dangerous CR controls (#499) (14e1dad)
• security: enforce CR reference authorization (#500) (875b999)
• security: enforce hardened contract for unsafe controls (#502) (6b8f2ad)
• security: require provenance for managed resources (#505) (fd39a1e)
• self-init: make bootstrap config one-shot (#514) (cc5876c)