D-068 item 1 -- OpenBao / off-EOL-vault assessment (RESEARCH DRAFT)

Status: RESEARCH INPUT ONLY (2026-07-06, jumphost stream, web research). The D-068 off-EOL path decision remains OPEN and operator-ruled; this draft exists so the B2 discussion starts from verified facts. Items that could not be confirmed are marked UNVERIFIED. Companion: docs/D-068-vault-1.8-vs-1.16-analysis.md (the 1.16 ruling).

Summary

OpenBao is healthy upstream (Linux Foundation, MPL-2.0; latest stable 2.5.5, 2026-06-17) and API-compatible for our surfaces (kv v1/v2, AppRole, PKI). BUT: no Juju charm for OpenBao exists anywhere (Charmhub API search empty, 2026-07-06), and OpenBao REMOVED the MySQL storage backend (raft/postgres only; upstream issue #651). An OpenBao path today = bespoke charm development we would own + a storage migration -- it cannot serve our 18 V0 certificates relations.
No plan exists to bring tls-certificates V1 to the legacy/reactive OpenStack charms. Canonical's V1 world is Sunbeam ("Canonical OpenStack", 2024.1 LTS, up-to-12-year support): vault + manual-tls-certificates + traefik on V1. The charm-guide still documents legacy TLS via the V0 vault relation. Practical read: V1 will likely NEVER come to the reactive set; "wait for V1" is risk acceptance without a deadline. (Absence-of-evidence finding -- flagged as such.)
The operator-lineage vault charm moved on (tracks to 1.19 + a new 2.0 track, 2026-07-02, tracking IBM Vault 2.0 GA 2026-04-14) -- same disqualifiers as the ruled-out 1.16 (V1-only, Raft-only, BUSL). The reactive 1.8/stable charm is in steady-state maintenance and still being rebuilt (Charmhub revision 2026-07-03).
CVE posture of 1.8.8: no known unauthenticated remote-compromise CVE applies to an internal-only, AppRole-driven, TLS-issuing deployment. Notable but gated: CVE-2021-45042 (PKI wildcard issuance to AUTHORIZED users, medium, in-range); CVE-2024-2048 (cert-auth bypass, 9.8 -- only if the cert auth method is enabled, ours is not); Aug-2025 "Vault Fault" set incl. CVE-2025-6000 RCE (requires privileged plugin-catalog access; per-CVE 1.8.8 applicability UNVERIFIED). Honest characterization: manageable today, unauditable tomorrow -- nobody assesses 1.8.8 anymore; each future disclosure needs our own analysis with no patch option. Supports deadline-bound acceptance, not indefinite stay.

Candidate paths compared

Wait-for-V1 in legacy charms -- no published plan; strong signal V1 investment goes to Sunbeam only. Equivalent to acceptance WITHOUT a deadline. Reject as a plan; it is the null hypothesis.
OpenBao now -- right long-term horse upstream, but requires (a) a charm that does not exist (bespoke, we own it), (b) storage migration off MySQL, (c) an aggressive support cadence (only latest cycle maintained). Not viable as a like-for-like swap; keep on the WATCH list (an OpenBao charm appearing, or any Canonical position on OpenBao, changes this materially).
Risk-acceptance with a hard deadline (research recommendation) -- stay on 1.8/stable (Canonical still rebuilds it; commercially supported under Pro/PCB). Compensating controls: mgmt-plane-only API exposure, audit logging shipped, minimal policies, confirm userpass/cert auth methods and plugin registration absent, unseal/root discipline (already the norm -- D-069). Hard re-decision deadline proposed: 2027-04. Two measured follow-ups (log only, do not execute): (a) whether the reactive charm's vault SNAP CHANNEL can be raised above 1.8 toward 1.14.x, the last MPL payload -- would de-EOL the payload WITHOUT touching relation topology; Canonical support for this UNVERIFIED; needs on-host measurement (charm config + snap tracks), a read-only look; (b) track Sunbeam feature parity -- the durable exit from the V0 certificates world is a PLATFORM decision, not a vault swap.

Decision hooks for the operator (nothing ruled yet)

Adopt path 3 with deadline? (Composes with keeping path 2 on watch.)
Authorize the read-only snap-channel headroom measurement (follow-up a)?
Fold "Sunbeam parity watch" into the Roosevelt planning inputs?
D-068 items 2 (listener TLS) and 3 (AppRole TTL audit) are unaffected by this and proceed on their own track.

Sources (accessed 2026-07-05/06; full trail)

openbao.org: release-notes 2.6.0-beta (2026-06-22); blog/roadmap-2.0 (LF governance); docs/configuration/storage; docs/guides/migration
endoflife.date/openbao (2.5.5 latest stable, 2026-06-17; latest-cycle-only support)
github.com/openbao/openbao issue #651 (MySQL backend removed/requested)
api.charmhub.io/v2/charms/find?q=openbao (EMPTY, 2026-07-06); charmhub.io/openbao (404)
charmhub.io/vault (tracks 1.5-1.19 + 2.0 candidate/beta/edge; 1.8/stable rev 2026-07-03)
canonical-vault-charms.readthedocs-hosted.com (2.0 upgrade docs; 1.8-vs-1.15 differences)
opendev.org/openstack/charm-vault commits (steady-state; last commit 2025-10-29)
docs.openstack.org/charm-guide latest: admin/security/tls (V0 model current)
canonical-openstack.readthedocs-hosted.com: vault feature, service-endpoint-encryption, release-cycle (Sunbeam 2024.1 LTS, 12-year support)
infoq.com 2026/04 vault-2-0-ibm-identity + IBM support-lifecycle addendum (Vault 2.0 GA 2026-04-14; 1.21->2.0 renumbering)
nvd.nist.gov CVE-2024-2048 (9.8 NIST / 8.1 vendor; <=1.14.9; cert auth only)
cyata.ai vault-fault (Aug-2025 nine zero-days incl. CVE-2025-6000 RCE)
stack.watch + cvedetails (historic ranges; NOTE conflicting aggregator text for CVE-2021-45042 / CVE-2021-43998 -- re-check NVD before quoting in a decision record)
stackhpc-kayobe-config readthedocs stackhpc-2025.1 configuration/openbao (non-Juju OpenStack distro already uses OpenBao for internal PKI)
duokey.com BUSL-change/OpenBao-migration backgrounder (2023-08-10 BUSL date)

NOT confirmed despite searching: any Canonical statement on OpenBao; any V1 plan for legacy charms; exact Vault 1.8.x EOL date/final point release; per-CVE applicability of the 2025 Cyata set to 1.8.8; reactive-charm snap-channel headroom (needs on-host measurement, not web research).