0.5.3

OpenBao Operator 0.5.3 rebuilds the manager and helper images with Go 1.27.3
to address CVE-2026-111943, the eMudhra intermediate CA compromise.

Security

Go 1.27.3 rejects certificate chains containing any of the eight compromised
public keys. This protects TLS clients that trust public certificate authorities,
including object storage clients and OpenBao clients configured for public ACME.
Supplying a custom storage CA does not remove this exposure in older operator
images because storage clients add that CA to the system trust pool.

The release updates the manager, init, backup, and upgrade images. It does not
change the API, CRDs, admission policies, or RBAC. It does not rebuild or update
the separate OpenBao server image or other external clients.

Read the Go security advisory and
Mozilla incident report.

Upgrade from 0.5.2

Finish active backups, restores, and OpenBao upgrades before updating the
operator. Upgrade the chart, manager, and helper images to 0.5.3. With Helm
--reuse-values, set image.tag and operatorVersion to 0.5.3, and clear or
replace an older image.digest pin. Update any helper image overrides to the
matching 0.5.3 images. Use verified mirrored references when a private registry
supplies the images.

Verify the init image of every managed OpenBao Pod after upgrading the manager.
Existing Pods retain helper binaries installed by their old init container until
those Pods are replaced. A successful Helm --wait does not prove that this
replacement is complete. BlueGreen voter StatefulSets use OnDelete, so a
template update or spec.runtime.restartAt change alone does not replace them.

If any Pod retains an old init image, use the
planned maintenance authorization procedure
to replace those Pods one at a time. Preserve Raft quorum. Wait for each
replacement to become Ready and verify cluster health before replacing the next
Pod. Disable maintenance mode when the replacements are complete. New backup
and upgrade Jobs must also use the matching helper images.

Certificates that chain through the compromised intermediates fail verification
after this update. Replace affected certificates with certificates from an
unaffected CA. Do not disable TLS verification to restore connectivity.

The operator upgrade harness checks runtime upgrades from 0.5.2. The release
retains the historical 0.5.0 API migration fixture.

Upgrade from 0.5.1

Follow the 0.5.2 upgrade guidance
before applying the 0.5.3 CRDs and admission policies. That guidance covers the
PROXY protocol configuration correction, restore storage requirements, and
KubeBao image coordinates.

Upgrade from 0.5.0

Follow the 0.5.1 migration guidance
and the 0.5.2 upgrade guidance before upgrading to 0.5.3. The release retains
the 0.5.0 API wire format.

0.5.3 (2026-10-20)

Bug Fixes

• security: reject compromised CA keys with Go 1.27.3 (#879) (7922c39)

0.5.2

OpenBao Operator 0.5.2 fixes scheduled backup initialization, PVC admission,
OpenBao Service endpoints, and restore executor safety. It also adds trusted
PROXY protocol source configuration and updates security and release tooling.

Fixes

In 0.5.1, clusters without status.backup.nextScheduledBackup calculate a future
deadline on each reconcile but do not persist it. Scheduled backups can remain
idle indefinitely. Clusters with a persisted deadline can continue to run backups.

The backup manager now persists the first deadline before it waits, observes an
active Job, or returns because backup execution is blocked. A failed status write
returns an error for retry. Initialization preserves an existing deadline and
backup history from the current API object.

After upgrading, check that status.backup.nextScheduledBackup is populated.
Verify a completed scheduled backup through status.backup.lastBackupTime and
status.backup.lastBackupName. A deadline alone does not prove that a snapshot
has reached object storage.

The release also includes these fixes from main:

• Accept narrowly scoped PVC binding updates from the AKS control plane and
  CSI leak-protection finalizer updates from storage provisioners.
• Exclude helper Job Pods from OpenBao API, headless, metrics, read-replica,
  and ACME Service endpoints.
• Stage restore snapshots on disk before submission, with an 8 GiB snapshot
  limit and a 30-minute preparation deadline. Disable executor restarts and
  destructive request redirects or body replay.
• Configure trusted PROXY protocol source IP addresses and CIDRs with
  spec.configuration.listener.proxyProtocolAuthorizedAddrs.
• Update Go to 1.27.2, golang.org/x/net to 0.60.0, and release-please's
  vulnerable dependencies. Retain the 0.5 cloud storage SDK versions.
• Repair artifact lookup, historical attestation discovery, documentation
  navigation, and local Staticcheck compatibility.

Upgrade from 0.5.1

Finish active backups, restores, and OpenBao upgrades before updating the
operator. Apply the release CRDs and admission policies before upgrading the
Helm release. The PROXY protocol correction adds a CRD field and admission
validation.

Replace proxyProtocolBehavior: allow_any with allow_authorized and a
nonempty proxyProtocolAuthorizedAddrs list. OpenBao does not support
allow_any; the operator now reports that configuration error before starting
the workload. deny_unauthorized also requires the address list. Include the
source addresses of operator clients and health probes when using that mode.

Restore executor Jobs require 9140 MiB of ephemeral storage. Check node
capacity before submitting a restore. Snapshots larger than 8 GiB fail before
submission. A failed executor does not retry the destructive operation.

New 0.5.2 manager images, helper images, and charts use the KubeBao GHCR namespace.
With Helm --reuse-values, set image.repository to ghcr.io/kubebao/openbao-operator,
set image.tag and operatorVersion to 0.5.2, and clear or replace an older
image.digest pin. Update any helper image overrides to matching 0.5.2 images.
Use verified mirrored references when a private registry supplies the images. Historical
0.5.1 artifacts retain their dc-tec publisher identity. Verify signatures and
attestations against the publisher of the selected release.

Upgrade from 0.5.0

Follow the 0.5.1 migration guidance before applying the 0.5.2 CRDs and admission
policies. The release retains the 0.5.0 API wire format. The operator upgrade
harness checks runtime upgrades from 0.5.1 and preserves the historical 0.5.0
API migration fixture.

New contributors

Thank you to our new contributors:

• @robertdebock for fixing AKS PVC binding
  admission in #791.
• @pennycoders for fixing admission of CSI
  leak-protection finalizers in #804.

0.5.2 (2026-10-13)

Bug Fixes

• release: backport compatible fixes for 0.5.2 (#809) (0dd7035)

0.5.1

OpenBao Operator 0.5.1 adds OpenBao 2.7.0 compatibility, updates the default
validation target to OpenBao 2.6.3, and includes lifecycle fixes and dependency
updates since 0.5.0.

What 0.5.1 changes

OpenBao 2.6.3 becomes the default validation target. OpenBao 2.7.0 adds external
KMS plugins for seals that earlier OpenBao versions included in the server. The
operator checks for a matching plugin before preparing a 2.7 workload or starting
an upgrade. It also accepts plugin metadata that OpenBao 2.7 can infer, while
retaining the required metadata for earlier versions.

The candidate includes the backup retention and partial-upload fixes, rolling
upgrade conflict retries, BlueGreen rollback and abort guards, restore status
preservation, readiness checks, and dependency updates merged since 0.5.0.

Upgrade from 0.5.0

Finish active OpenBao upgrades, backups, and restores before updating the
operator. Take and verify a current backup. Review the generated CRD comparison
and qualification results for the final candidate commit.

The candidate retains the 0.5.0 API wire format. The plugin version,
binaryName, and sha256sum fields become optional in the CRD. Runtime
validation still requires them when the selected OpenBao version needs them.

Upgrade the operator before changing an OpenBao cluster to 2.7.0. For AWS KMS,
Azure Key Vault, Google Cloud KMS, OCI KMS, and PKCS#11 seals, declare the matching
external KMS plugin and provide its runtime dependencies before changing the
server version. Verify access to the existing seal key and qualify the exact
plugin version against a restored copy of the cluster data.

OpenBao 2.7 also removes some built-in authentication and secrets plugins.
Inventory enabled plugins before the server upgrade. Follow the
OpenBao 2.7 migration procedure
for the operator configuration and upstream migration references.

The SoftHSM fixture uses PKCS#11 plugin 0.1.0. Qualification does not cover vendor
HSMs, cloud KMS access, or the PKCS#11 0.2.0 root-key rewrap transition. The guard
against pre-2.6 to 2.6-or-newer BlueGreen transitions remains in place.

0.5.1 (2026-09-23)

Features

• compat: qualify OpenBao 2.7 external seal plugins (#762) (94b18f2)

Bug Fixes

• api: clarify missing TLS rotation period validation (#751) (017a5bd)
• backup: abort partial uploads when the snapshot stream fails (#759) (6d02c45)
• backup: keep the newest snapshot when applying retention (#757) (6668b31)
• backup: limit retention to scheduled backup keys (#758) (7a86183)
• backup: preserve trigger before job creation (#703) (ee44f8e)
• metrics: clear finalized reconciliation series (#721) (fc15f5e)
• metrics: keep cluster phase gauges one-hot (#716) (f4c2e1a)
• readiness: require synchronized caches and fresh admission checks (#720) (4764ab9)
• startup: validate platform discovery and return errors (#717) (4197f3c)
• status: preserve restore state in final adminops patch (#710) (e362877)
• upgrade: correct peer identity, rollback retries, and rollout verification (2b1f646)
• upgrade: guard blue/green rollback and preserve active inputs (#755) (ac197df)
• upgrade: limit blue/green abort to phases before promotion (#754) (6518d2b)
• upgrade: retry transient rolling partition conflicts (#753) (b029ff6)

Performance Improvements

• kube: reuse apply responses for ownership verification (#739) (a64fd38)
• raft: avoid redundant Autopilot configuration writes (#737) (4b80116)

0.5.0

OpenBao Operator 0.5.0 documents the compatibility commitment selected for
parts of the openbao.org/v1alpha1 API. The API remains alpha; this is a
release-planning boundary, not a declaration that all of v1alpha1 is stable.
The release also makes restore and upgrade execution safer when the controller
restarts or loses track of a Kubernetes Job.

The release adds OpenBao 2.6 integration, validates Kubernetes 1.36 as the
primary target, and improves voter sizing, tenant cleanup, Gateway readiness,
and validation-hook security. This release does not introduce v1beta1.

What 0.5.0 changes

A defined compatibility boundary within v1alpha1

The project now records which selected fields are intended to retain their
current behavior, what omission means, which updates are allowed, and which
conditions clients can rely on. A generated field inventory and CRD comparison
make that boundary reviewable. Newer feature groups remain outside the selected
contract and can still change before a beta API release.

Durable recovery and upgrade operations

Restore execution now records durable receipts for preparation, Job creation,
terminal observation, and post-restore recovery. If a committed restore Job
disappears, the operator reports the unknown outcome instead of repeating a
potentially destructive restore. After snapshot application, it restarts voters
and restores the declared read-replica state before marking the operation
complete.

BlueGreen validation hooks now have an identity tied to a specific upgrade
attempt. A Job from an earlier attempt cannot satisfy a later upgrade, and a
recorded terminal hook is not replayed after its Job disappears. Rolling
upgrades also preserve leader ordering across revisioned workloads.

Backup cleanup preserves unrelated Secret owners. Scheduled backup observation
no longer treats a pre-upgrade snapshot Job as the scheduled backup Job.

OpenBao 2.6 integration

OpenBao 2.6.2 is the primary OpenBao validation target. The release adds:

• plugin-backed key management service (KMS) seal configuration through
  spec.unseal.type: kms;
• multi-value headers and conditional when expressions for self-init requests;
• idle strategy changes between RollingUpdate and BlueGreen, without
  replacing the active StatefulSet or its persistent volume claims (PVCs); and
• independent resource configuration for voter OpenBao containers through
  spec.resources.

Plugin-backed KMS support configures OpenBao but does not install a plugin
binary or vendor libraries. Supply the plugin through spec.plugins, mount
sensitive runtime data through spec.unseal.credentialsSecretRef, and keep
secrets out of spec.unseal.kms.config.

Kubernetes and multi-tenant operation

Kubernetes 1.36.1 is the primary Kubernetes validation target. Release gates
also cover the Kubernetes 1.34.x and 1.35.x compatibility lines. The release
adds an operator-upgrade test from 0.4.2 across Development, Transit, and
three-voter Hardened clusters.

Gateway readiness now follows the managed Route Accepted and ResolvedRefs
conditions. External certificates must contain every configured extraSANs
value. Custom BlueGreen validation-hook images use
spec.operatorImageVerification and run with a restricted Job security
context.

OpenBaoTenant now reports a generation-aware Provisioned condition. The
provisioner keeps shared namespace resources while another tenant claim exists
and removes its role-based access control (RBAC), ResourceQuota, and
LimitRange resources after the last claim ends. Single-tenant Helm
installations now derive the controller watch namespace consistently from
tenancy.targetNamespace.

Before you upgrade

Upgrade 0.4.0 or 0.4.1 installations to 0.4.2 first. Finish any active OpenBao
version upgrade, backup, or restore, then take and verify a current backup. Keep
the 0.4.2 controller and custom resource definitions (CRDs) installed while you
update stored manifests, Hardened credentials, and restore authorization.
Kubernetes can prune fields that do not exist in the new structural schema, so
do not apply the 0.5.0 CRDs before you complete these changes.

The 0.4.2-to-0.5.0 CRD comparison reports eight removed paths and five tightened
validation groups. The following sections cover the required actions.

Update restore authorization

OpenBao Operator 0.5.0 uses the seal-validating
sys/storage/raft/snapshot endpoint when spec.force is omitted or false.
Earlier releases always used sys/storage/raft/snapshot-force.

Existing restore identities must grant the normal endpoint before you upgrade
the controller. Self-init does not rewrite policies after initialization. Add:

path "sys/storage/raft/snapshot" {
  capabilities = ["update"]
}

Keep a separate update grant on sys/storage/raft/snapshot-force only when
the identity must support spec.force: true. Clusters initialized by 0.5.0
receive both grants in the generated restore policy.

Migrate Hardened unseal credentials

The 0.5.0 admission policy rejects prohibited inline credentials in every
submitted Hardened OpenBaoCluster, including an update to an existing object.
Create the replacement Secret or workload identity first. While 0.4.2 is still
installed, submit one update that adds spec.unseal.credentialsSecretRef or the
workload identity and removes the prohibited inline fields:

Provider	Remove	Replacement
AWS KMS	spec.unseal.awskms.secretKey and sessionToken	Workload identity or Secret keys AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and optional AWS_SESSION_TOKEN
Azure Key Vault	spec.unseal.azureKeyVault.clientSecret	Managed or workload identity, or Secret keys AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET
Transit	spec.unseal.transit.token	Secret key token
PKCS#11	spec.unseal.pkcs11.pin	Secret key BAO_HSM_PIN

After the 0.5.0 admission policy is installed, the API server rejects later
updates while any prohibited inline field remains. Hardened plugin-backed KMS
configuration must also keep spec.unseal.kms.config empty and provide secrets
through external identity or files mounted from credentialsSecretRef.

Update stored manifests

Complete these changes while the 0.4.2 CRDs remain installed:

1. Move each Automatic Certificate Management Environment (ACME)
   spec.tls.acme.domain value into the spec.tls.acme.domains list.
2. Move spec.maintenance.restartAt to spec.runtime.restartAt. Keep
   spec.maintenance.enabled if you still use maintenance mode.
3. Add the provider block selected by each non-static spec.unseal.type.
   Remove all unselected provider blocks.
4. Remove gcs and azure blocks from S3 backup and restore targets.
5. Remove roleArn from backup and restore targets that do not use S3.
6. Set an explicit endpoint for every S3 backup and restore target.
7. Remove spec.upgrade.tokenSecretRef, including null placeholders.
   Configure spec.upgrade.jwtAuthRole when the self-init OpenID Connect (OIDC)
   bootstrap role is not available.
8. Replace image-tag aliases or partial OpenBao versions with a complete
   semantic version such as 2.6.2.

For example, migrate this 0.4.2 configuration:

spec:
  tls:
    acme:
      domain: bao.example.com
  maintenance:
    enabled: true
    restartAt: "2026-08-01T12:00:00Z"
  unseal:
    type: transit
    transit: {address: https://transit.example.com, keyName: autounseal, mountPath: transit}
    awskms: {region: eu-west-1, kmsKeyID: alias/unused}

Use this 0.5.0 configuration:

spec:
  tls:
    acme:
      domains:
        - bao.example.com
  maintenance:
    enabled: true
  runtime:
    restartAt: "2026-08-01T12:00:00Z"
  unseal:
    type: transit
    transit: {address: https://transit.example.com, keyName: autounseal, mountPath: transit}

The operator owns the removed status aliases. status.backup.lastBackupTime
replaces status.lastBackupTime. The structured status.upgrade.failure
fields reason, message, and at replace lastErrorReason,
lastErrorMessage, and lastErrorAt. The 0.4.2 controller writes both forms,
so the upgrade preserves backup and upgrade failure state.

Check affected integrations

Review these configurations before you resume their operations:

• Scheduled backups and pre-upgrade snapshots without an effective JSON Web
  Token (JWT) role must set spec.backup.tokenSecretRef. The operator no longer
  falls back to a <cluster>-root-token Secret.
• Hardened clusters with backups or either pre-upgrade snapshot setting must
  define non-empty, port-scoped spec.network.egressRules. The backup target
  must also use credentialsSecretRef, workloadIdentity, or S3 roleArn
  instead of ambient storage credentials.
• Hardened clusters with custom BlueGreen validation hooks need a blocking
  spec.operatorImageVerification policy that trusts the hook publisher.
• External TLS certificates must contain every configured extraSANs value.
• Gateway users must wait for Route Accepted=True and ResolvedRefs=True
  before expecting GatewayIntegrationReady=True.
• A cross-cluster restore to a target with different ServiceAccount subjects
  needs those subjects in the source OpenBao JWT roles before the snapshot is
  taken. Configure spec.selfInit.oidc.additionalSubjects before source
  self-initialization, or update the roles directly. A different Kubernetes
  control plane also requires separate JWT issuer and signature trust.

Upgrade from 0.4.2

After you update authorization and stored manifests, apply the 0.5.0 CRDs:

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

Then upgrade the Helm release:

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

0.5.0-rc.6

0.5.0-rc.6 (2026-08-28)

Bug Fixes

• upgrade: resolve leaders on revisioned rolling workloads (#674) (3c8e58d)

0.5.0-rc.4

0.5.0-rc.4 (2026-08-25)

Bug Fixes

• release: honor exact versions in manifest mode (#650) (007397f)
• release: isolate pending label cleanup (#646) (2538473)

0.5.0-rc.3

0.5.0-rc.3 is the first published release candidate for OpenBao Operator
0.5.0. Use it only in evaluation and staging environments. Do not use it in
production. During the candidate period, the project will run manual cluster
tests. The project will also monitor upgrades, lifecycle operations, security
controls, and release artifacts.

The candidate serves the openbao.org/v1alpha1 API. It does not add
v1beta1. The 0.5.0 release notes contain the full release description and
migration procedure. RC3 also corrects release-only automation. Image scans
check out the tagged repository. The prior-stable operator upgrade test serves
candidate images from a pinned registry on the Kind network. Release packaging
preserves the reviewed Artifact Hub metadata, and post-release verification
checks the complete published asset and attestation set. It compares normalized
chart metadata because Helm rewrites YAML key order and quoting when it packages
the chart.

What to Test

• Test the candidate on Kubernetes 1.36.x. Also exercise Kubernetes 1.34.x
  and 1.35.x when those versions are in your support window.
• Rehearse the operator upgrade from 0.4.2. Test Development, Transit, and
  three-replica Hardened clusters. Verify reconciliation and managed resource
  identity. Verify that stored data remains available.
• Update stored manifests before you install the candidate custom resource
  definitions (CRDs). Replace spec.tls.acme.domain and
  spec.maintenance.restartAt. Remove the deprecated status aliases. The 0.5.0
  migration procedure lists the replacement fields.
• Test backup and restore. Verify stored-data continuity. Test a strategy change
  between RollingUpdate and BlueGreen while the cluster is idle.
• Test plugin-backed key management service (KMS) seal configuration if you use
  this feature. Also test the OpenBao 2.6 self-init headers and when
  controls. OpenBao 2.6.2 is the primary validation version.
• Verify signatures and attestations for the images, chart, checksums, software
  bills of materials (SBOMs), manifests, and release provenance. Verify them
  against the 0.5.0-rc.3 tag.

Install or Upgrade in an Evaluation Environment

Apply the candidate CRDs before you upgrade the controller or Helm release:

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

Upgrade the Helm release with the candidate chart:

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

First upgrade each 0.4.0 or 0.4.1 installation to 0.4.2. Keep the 0.4.2 CRDs
and controller installed while you update stored manifests. Kubernetes can
prune removed fields after you install the candidate CRDs.

Candidate Limits

• The operator blocks a BlueGreen OpenBao upgrade from a version before 2.6
  to version 2.6.x. Mixed versions cannot complete the request-forwarding
  health checks. Change an idle cluster to RollingUpdate before you request
  this OpenBao upgrade.
• Plugin-backed KMS support configures OpenBao. It does not install the plugin
  binary. It does not supply vendor libraries, devices, or persistent
  plugin-cache storage.
• The release process does not create a patch-level documentation snapshot for
  this candidate. Unreleased changes continue under /docs/next until the
  stable 0.5.0 documentation line is published.

Report each confirmed regression with the candidate version and Kubernetes
version. Include the OpenBao version, profile, and upgrade strategy. Include
the relevant operator conditions and sanitized events.

0.5.0-rc.3 (2026-08-25)

Bug Fixes

• release: unblock RC publication checks (#642) (ff5c506)
• release: compare packaged chart metadata semantically (776a8d0)

Miscellaneous Chores

• main: request release 0.5.0-rc.3 (#643) (486d2ea)

0.4.2

OpenBao Operator 0.4.2 allows an existing OpenBaoCluster to change its
upgrade strategy while the cluster is healthy and idle. This gives clusters
configured for BlueGreen a supported path to use the validated rolling
upgrade to OpenBao 2.6.x without snapshotting and recreating the cluster.

If you do not use BlueGreen and do not plan to switch to it, there is no need
to update from OpenBao Operator 0.4.1 to 0.4.2. Version 0.4.1 already supports
the validated rolling upgrade to OpenBao 2.6.x. Upgrade to 0.4.2 when an
existing cluster needs to change its upgrade strategy.

Idle Upgrade Strategy Switching

Initialized clusters can now change spec.upgrade.strategy in either
direction:

• BlueGreen to RollingUpdate
• RollingUpdate to BlueGreen

The operator accepts a strategy change only after every voter and configured
read replica is Ready, status.currentVersion equals spec.version, and no
upgrade, rollback, backup, restore, resize, restart, Green workload, pending
request, failure, operation lock, or safe-mode recovery is active. Unsafe
changes are rejected with recovery guidance.

Patch only spec.upgrade.strategy, then wait for
status.acceptedUpgradeStrategy to report the requested strategy before
changing spec.version, spec.image, replicas, storage, or restart controls.
The active StatefulSet and its PVCs remain the stable workload during the
strategy transition.

Switching to BlueGreen requires a resolvable upgrade executor image and a JWT
role with the BlueGreen upgrade capabilities. Self-init policies created for a
rolling-origin cluster are not rewritten by a later strategy change, so update
that role policy before requesting BlueGreen when necessary.

OpenBao 2.6.x Upgrade Guidance

The mixed-version OpenBao incompatibility remains: a pre-2.6 Blue leader cannot
safely promote a 2.6-or-newer Green revision. OpenBao Operator continues to
block that BlueGreen transition before deploying Green.

For an existing pre-2.6 cluster configured for BlueGreen:

1. Upgrade the OpenBao Operator CRDs and controller to 0.4.2.
2. Let the cluster return to a healthy BlueGreen Idle state.
3. Change only spec.upgrade.strategy to RollingUpdate.
4. Wait for status.acceptedUpgradeStrategy=RollingUpdate.
5. Request the OpenBao 2.6.x version change separately.

Do not combine the strategy and OpenBao version changes in one request.
Clusters that already use RollingUpdate can remain on OpenBao Operator 0.4.1
for the validated OpenBao 2.6.x rolling upgrade.

CRD Upgrade Required

This patch adds status.acceptedUpgradeStrategy and
status.upgrade.blueGreen.blueControllerRevision to the OpenBaoCluster CRD.
Apply the 0.4.2 CRDs before upgrading the controller. Helm does not upgrade
installed CRDs automatically:

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

The existing 0.4.0 versioned documentation remains the release-line snapshot
and has been refreshed with the strategy-switch procedure, OpenBao 2.6.x
guidance, and the new status fields.

0.4.2 (2026-07-15)

Bug Fixes

• upgrade: allow idle strategy switching on 0.4.x (#552) (3501400)

0.4.1

0.4.1 restores compatibility with OpenBao 2.6.0 for fresh clusters and rolling
upgrades that do not configure external plugins, and for hardened clusters that
verify the official OpenBao image signature. It also prevents an unsafe
mixed-version BlueGreen upgrade from starting.

Compatibility Fix

OpenBao Operator 0.4.0 always rendered plugin_directory = "/openbao/plugins"
into the OpenBao server configuration, even when the cluster did not configure
plugins and therefore had no plugin directory mounted. OpenBao 2.6.0 initializes
the new KMS plugin catalog during startup and rejects that missing directory,
causing fresh OpenBao 2.6.0 clusters and 2.5.5 to 2.6.0 rolling upgrades to
stall with the following error:

Error creating KMS plugin catalog: expand plugin directory: lstat /openbao/plugins: no such file or directory

The operator now renders plugin_directory only when spec.plugins is
configured. Clusters that use plugins retain the existing plugin-directory
configuration and mounts.

Hardened Image Verification

OpenBao 2.6.0 moved container-image publication and signing from the
release.yml workflow to release-images.yml. The hardened profile's default
keyless verification policy in OpenBao Operator 0.4.0 trusted only the earlier
workflow identity, so it rejected the official OpenBao 2.6.0 image before
creating the cluster workload.

The default policy now trusts tag-bound signatures from both official OpenBao
release workflows. Branch builds and unrelated workflows remain untrusted, and
the earlier identity remains accepted for supported OpenBao 2.4 and 2.5 images.

BlueGreen Upgrade Limitation

OpenBao 2.6.0 changed the internal request-forwarding gRPC service name used by
Raft Autopilot health checks. During a pre-2.6 to 2.6.0 BlueGreen upgrade, Green
peers cannot report healthy to the Blue leader and therefore cannot be promoted
safely. OpenBao Operator 0.4.1 rejects pre-2.6 to 2.6-or-newer BlueGreen
transitions before creating Green resources. Successful BlueGreen coverage
continues on OpenBao 2.4.4 to 2.5.5, while rolling coverage qualifies 2.5.5 to
2.6.0.

The operator also verifies the actual Raft voter state after a promotion
request. A response that says the peer is already a voter is no longer accepted
without confirming that state in the Raft configuration.

Upgrade Guidance

Upgrade OpenBao Operator to 0.4.1 before changing an OpenBaoCluster from an
earlier OpenBao release to OpenBao 2.6.x. Clusters already configured for
RollingUpdate can then use the validated 2.5.5 to 2.6.0 path. Do not attempt an
OpenBao 2.6.x upgrade while the cluster is still managed by OpenBao Operator
0.4.0 unless a valid plugin directory is explicitly present.

Clusters already configured for BlueGreen must wait for an operator release
that qualifies an upstream compatibility fix, or restore a backup into a new
2.6.0 cluster. Strategy changes remain immutable in 0.4.1; safe idle-only
switching is tracked in
#548.

This patch does not change the CRDs. The existing 0.4.0 documentation snapshot
remains the release-line snapshot and has been refreshed with the OpenBao 2.6
compatibility matrix and examples.

0.4.1 (2026-07-15)

Bug Fixes

• compat: support OpenBao 2.6.0 on 0.4.x (#547) (dbba4fd)
• config: omit plugin directory without plugins (763a433)

---

This PR was generated with Release Please. See documentation.

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)