0.4.0

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.

0.4.0 (2026-07-04)

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)