# 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).
