# 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

1. **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.
2. **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).
3. **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).