# D-068 item 1 -- re-scoped Vault migration plan (DRAFT for operator ruling) **Backs:** D-068 item 1 ("Vault version"), re-scoped per the 2026-07-05 amendment ("get off EOL 1.8" stays OPEN; 1.16 ruled OUT as the path). **Type:** options paper -- NOTHING here is adopted; the operator rules per GA-R5, one sub-question per exchange. **Date:** 2026-07-23. **Authored by:** session agent at operator direction ("Draft now", queue-pass session). **Evidence base:** `docs/D-068-vault-1.8-vs-1.16-analysis.md` (2026-07-05, all of whose findings this draft treats as still-current UNLESS re-verified below) + two dated web probes (section 5). ## 1. The re-scoped question The original item 1 question ("pin 1.16 and rehearse the upgrade") is DEAD -- the 2026-07-05 analysis proved the new operator charm incompatible with this reactive cloud on five measured axes (certificates V0->V1 showstopper, Raft-only storage, no upgrade path, Ceph breakage reports, BUSL licensing). What remains is really THREE questions, and this draft proposes ruling them separately (a bundled ruling would violate the one-decision-per-exchange rule and they have different deadlines): - **Q1 (interim posture):** what risk posture covers EOL Vault 1.8.8 for the REHEARSAL phases (VR0 testcloud, VR1 when Stage 5 brings Juju/Vault)? Deadline: now-ish -- it is the standing state. - **Q2 (Roosevelt path):** what is the PRODUCTION plan to get off 1.8? Deadline: Roosevelt Vault design time (alongside D-068 item 2's listener-TLS build requirement and D-132's MAAS topology, which are pinned to the same design window). - **Q3 (trigger/review):** what re-checks, on what cadence, keep Q2's inputs fresh so the design-time ruling is made on live facts, not this draft's? ## 2. Q1 options -- interim EOL posture (rehearsal phases) **(1a) Explicit risk-acceptance, bounded to rehearsal.** Record: Vault 1.8.8 is EOL and receives no security patches; accepted for VR0/VR1 because (i) no production tenant data or external exposure exists in the rehearsals, (ii) vault listens only on metal-internal, (iii) the D-069 unseal flow and SEC register already treat vault material as operator-only. Production (Roosevelt) is explicitly NOT covered -- Q2 owns that. Cost: a recorded acceptance + nothing else. This is the 2026-07-05 amendment's candidate (c), scoped to rehearsal only. **(1b) Risk-acceptance + compensating monitoring.** As (1a), plus a standing task: monitor published CVEs against Vault 1.8.x (no patches will exist; the monitoring informs WORKAROUNDS or an emergency re-rule, not upgrades). Cost: a recurring review item -- natural vehicle is D-071's ADOPTED monthly review trigger, one added checklist line. No new tooling. **(1c) Do nothing / leave implicit.** Rejected framing (listed for completeness): the current state is already de-facto acceptance, but this project's discipline records postures explicitly; an unrecorded acceptance is exactly the record-vs-reality gap the grounding audit existed to kill. Draft lean (for debate, not a decision): **(1b)** -- the delta over (1a) is one line in an already-adopted monthly review. ## 3. Q2 options -- the Roosevelt production path All four candidates carry the same hard constraint from the analysis: the 18 `vault:certificates` V0 relations are the coupling that matters; the Vault API itself is the EASY half. **(2a) Wait-and-re-assess: reactive charms gain tls-certificates V1.** The 2026-07-05 candidate (a). If the Caracal/successor service charms become V1 requirers, the new operator vault becomes viable and the migration is the documented backup/restore CA-replacement project (analysis section "migration cost", 6 workstreams). AS OF 2026-07-23 THERE IS NO SIGNAL OF THIS (section 5) -- so today this is a monitoring stance, not a plan. Risk: indefinite timeline owned by upstream; Roosevelt could reach design time with nothing to adopt. BUSL licensing review still owed if this path lands. **(2b) OpenBao payload under the EXISTING reactive charm (fork).** OpenBao is the MPL fork, actively released (section 5). NO Juju charm exists for it (section 5) -- but the coupling insight cuts the other way: the reactive `charm-vault` drives its payload over the Vault HTTP API, and OpenBao's API is compatible at the fork-point feature set this cloud uses (KV v2 + PKI + AppRole -- all pre-1.14 features; UNVERIFIED for our exact call surface, verify item V3). A fork of `charm-vault` swapping the payload snap/deb to OpenBao would keep ALL V0 relations, the MySQL storage backend, and the D-069 unseal flow intact -- because the CHARM is unchanged, only the daemon binary. Cost: we own a charm fork (build, test, security-patch tracking of OpenBao releases); a payload-swap migration on live state (storage format at the fork point is compatible BY DESIGN CLAIM -- verify item V4); this is real engineering with a permanent maintenance tail, but it is the only path that gets MAINTAINED, MPL-licensed software without waiting on upstream charm work. Roosevelt-delta: smallest of the modernizing options (cloud shape unchanged). **(2c) Shrink Vault's job first, then modernize the remnant.** Re-architect so vault is no longer the cloud-wide CA (move TLS issuance to another V0 `certificates` provider, or to an offline/enterprise CA workflow the charms already support via ssl_* config options -- the charm-guide documents both), leaving vault only as barbican's KV backend. The remaining single relation (`barbican-vault:secrets-storage`) is a far smaller compatibility surface to migrate to ANY maintained backend (new vault charm, OpenBao, or barbican's other backends). Cost: a TLS re-architecture across 18 services -- the highest-touch option operationally, and it trades a solved problem (vault CA works) for design work; but it removes the V0/V1 deadlock permanently and decouples the cloud's trust chain from the vault charm's fate. This option was NOT in the 2026-07-05 candidate list -- it is new in this draft and needs the most scrutiny. **(2d) Enter Roosevelt on 1.8 with a production risk-acceptance + remediation deadline.** The 2026-07-05 candidate (c) at production scope: deploy Roosevelt on the proven 1.8 stack, record a dated remediation obligation, and execute whichever of (2a)/(2b)/(2c) has matured by the deadline. This is honest about the possibility that nothing matures; it converts an unbounded wait into a bounded one. Requires item 2's listener TLS (already RULED: Roosevelt build requirement) as a mitigating layer. Commercial note: a multi-tenant cloud running an EOL secret store is a hard sell in any security review -- this option needs the operator's commercial risk judgment, not just technical. Draft lean (for debate): **(2d) as the Roosevelt BASELINE with (2b) as the funded remediation track** -- baseline keeps Roosevelt deployable on proven components; the OpenBao-payload fork is the only remediation whose timeline WE own. (2a) stays a free monitoring line either way. (2c) is the strategic long-term shape but should not gate Roosevelt's initial deploy. ## 4. Q3 -- triggers and review (proposed mechanics, not a decision) - Fold TWO lines into the D-071 monthly review checklist: (i) Vault 1.8.x CVE scan (Q1 posture 1b, if ruled); (ii) re-run the section-5 probes (V1 support signal; OpenBao charm ecosystem; OpenBao release cadence). - Hard trigger: at Roosevelt Vault DESIGN time, this draft's section 5 verifications are RE-RUN and the Q2 ruling is made on the fresh results -- this draft's probes will be stale by then and MUST NOT be cited as current. - If (2b) is ruled as remediation track: its verify items V3/V4 become the first funded work package, BEFORE any charm fork begins. ## 5. What was verified for this draft, and what was NOT Probes run 2026-07-23 (web search from the jumphost; both INCONCLUSIVE-BY- ABSENCE, which is evidence of no-signal, not proof of impossibility): - **V1 adoption:** no result indicates the reactive OpenStack service charms have gained tls-certificates V1 requirer support; current charm-guide TLS docs still describe the V0 vault workflow. - **OpenBao charm:** no Juju charm for OpenBao found; OpenBao itself shows an active release stream (openbao/openbao releases; third-party PKI writeups dated 2026-03). NOT verified here (owed before any Q2 ruling -- the verify-live list): - **V1:** `juju info vault` channel map + charm-vault upstream activity (is the reactive charm itself still maintained?). - **V2:** current Vault 1.8.8 CVE exposure list (informs Q1 urgency). - **V3:** OpenBao API compatibility against OUR exact call surface (KV v2 paths, PKI endpoints the charm drives, AppRole flows, `sys/` calls in `charm-vault`'s handlers). - **V4:** OpenBao's storage-format compatibility claim for a payload-swap on existing MySQL-backed state, at our data's fork-point version. - **V5:** BUSL vs MPL licensing review with counsel (only if a path involving Vault >=1.15 payload survives). ## 6. Proposed ruling sequence (each its own GA-R5 exchange) 1. Q1 interim posture: (1a) vs (1b). 2. Q2 Roosevelt path: baseline + remediation-track structure, or a single path -- options (2a)-(2d). 3. Q3 mechanics: adopt the D-071 checklist lines + the design-time re-verify trigger as written (or amended). No dependent work starts before its ruling. This document changes NOTHING by itself. ## Sources - Repo: `docs/D-068-vault-1.8-vs-1.16-analysis.md` (+ its cited Canonical/ Charmhub/OpenStack sources); `docs/design-decisions.md` D-068 + 2026-07-05 amendment, D-069, D-071, D-132. - Web (2026-07-23 probes): OpenStack charm-guide "Managing TLS certificates" (https://docs.openstack.org/charm-guide/latest/admin/security/tls.html); openstack/charm-vault (https://github.com/openstack/charm-vault); openbao/openbao releases (https://github.com/openbao/openbao/releases); canonical/self-signed-certificates-operator (V1-world provider example; https://github.com/canonical/self-signed-certificates-operator).