Skip to content

0.4.1

Choose a tag to compare

View all tags
@openbao-operator-release-tag openbao-operator-release-tag released this 15 Jul 08:28
Immutable release. Only release title and notes can be modified.
0.4.1
This tag was signed with the committer’s verified signature.
dc-tec Roel de Cort
GPG key ID: A5ABD477540DEB59
Verified
Learn about vigilant mode.
f159abe
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

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.

Assets 14
Loading