Fork: 0
OpenStack / openstack-caracal-dc-dc
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-dc-dc / docs / D-068-vault-migration-plan-draft.md
@JANeumatrix JANeumatrix 16 hours ago 9 KB D-068 item 1: re-scoped Vault migration plan drafted (options paper; nothing adopted)
Raw Blame History

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