diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 5501659..1330f3b 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -2414,7 +2414,10 @@ (+T16c/T16d failing-direction), binding-matrix reference row updated. gauntlet ALL GREEN 99.** F-CV1 and F-CV3 are TWO SEPARATE findings; F-CV3 (dashboard = charm https frontend not effective, bindings ARE correct) is STILL OPEN and needs its own triage session. Sweep: - docs/audit/queued-findings-20260806-phase03-coreverify.txt. + docs/audit/queued-findings-20260806-phase03-coreverify.txt. ACCESS-MODEL CONTEXT added 2026-08-06 + (dc-dc-deployment-workflow.md gap-21): operators reach the dashboard via the metal-admin VIP over + the tailnet -> argues the F-CV3 fix should serve TLS on metal-admin (option A), not metal-internal + (option B, which reverses ruled D-072). A-vs-B resolution is the next F-CV3 step. **NAMED-GATE DEFECT found by measurement -- `phase-03-core-verify.md` Step 3.1 asserts expected non-active/idle = 1 (octavia only); the VR1 roster yields 4 deferred-by-design + gss.** That gate is STALE for VR1 and a DOCFIX is owed (also owed on that runbook: `-m openstack` -> `-m vr1-dc0` diff --git a/docs/audit/queued-findings-20260806-phase03-coreverify.txt b/docs/audit/queued-findings-20260806-phase03-coreverify.txt index 03a020f..a83df4b 100644 --- a/docs/audit/queued-findings-20260806-phase03-coreverify.txt +++ b/docs/audit/queued-findings-20260806-phase03-coreverify.txt @@ -35,6 +35,10 @@ default-ssl.conf, NOT the charm's openstack_https_frontend.conf (glance, working, uses the charm frontend w/ SSLEngine on). Charm https frontend not effective for dashboard. SEPARATE finding from F-CV1 -- do NOT chase a common fix. Needs focused triage + gated remediation. + ACCESS-MODEL CONTEXT (2026-08-06): operators reach the dashboard via the metal-admin VIP over + the tailnet (dc-dc-deployment-workflow.md gap-register item 21 access-model note) -> argues for + the fix serving TLS on metal-admin (option A), NOT metal-internal (option B, which also reverses + ruled D-072). A-vs-B + whether apache can be steered onto metal-admin is the open (a) work. NOTE both: certs ARE present -> NOT the ovn CN-issuance class; NOT a missing certificates relation. Charm apache-TLS-frontend layer. Also owed with the Horizon-access remediation: diff --git a/docs/dc-dc-deployment-workflow.md b/docs/dc-dc-deployment-workflow.md index c9e1891..026db60 100644 --- a/docs/dc-dc-deployment-workflow.md +++ b/docs/dc-dc-deployment-workflow.md @@ -1184,6 +1184,40 @@ source IP in DC-side audit logs; it requires a return route for `100.64.0.0/10` on the served hosts. + **ACCESS-MODEL CONTEXT (2026-08-06 operator discussion -- NOT a ruling; context that + informs the four sub-decisions above when they are re-raised).** The operator extended + the standing model: *operators reach each DC's metal-admin plane over the tailnet AND + access ROUTED DASHBOARDS (Horizon) from there* -- i.e. a browser hitting the dashboard's + metal-admin VIP (`10.12.8.58` on dc0) directly over the tailnet, not just SSH. This has + consequences that reach OUTSIDE the Tailscale build and should be weighed with it: + - **Reverse proxy (operator path) becomes unnecessary.** The external nginx proxy that + fronts the PROVIDER VIP today (VR0's `10.12.4.7`, phase-03 Step 3.3) exists only + because corporate clients have no route in. The tailnet gives operators a route to + metal-admin, so the operator-facing proxy drops out; the TENANT path (provider VIP via + the edge/FIP) is separate and unaffected. Clean split: operators -> metal-admin VIP via + tailnet; tenants -> provider VIP via edge. + - **The per-rebuild proxy accommodations SUNSET for operators.** D-044 (Secure-cookie + override) and D-075 (root redirect) were artifacts of the PLAIN-HTTP proxy leg; over a + real HTTPS tailnet leg they are unneeded. D-044 already names this the "Roosevelt + sunset." + - **Certs become load-bearing on metal-admin.** Direct operator HTTPS to the metal-admin + VIP needs the dashboard cert to carry a SAN for `10.12.8.58` (and ultimately the FQDN + once `os-public-hostname` + FQDN-SAN certs land at Stage 7, D-106/D-008). The current + cert is minted for the provider VIP -- MEASURED apache warning `AH01909` on + `10.12.4.58:443` is the preview of this gap. + - **Binding placement -- reinforces metal-admin as the dashboard's serving plane.** This + is the access-model argument for F-CV3 option A (apache terminates TLS on metal-admin) + over option B (cluster->metal-internal): operators live on metal-admin, NOT the isolated + metal-internal svc plane (D-125). metal-internal is deliberately NOT advertised to the + tailnet, so a dashboard served only on metal-internal would be a plane operators cannot + reach. The rest of the API split is unaffected (public->provider tenant; admin->metal-admin + operators-via-tailnet; internal->metal-internal isolated). + - **Relevance to sub-decision (b).** This is an OPERATOR->DC access statement, consistent + with the star (not mesh) reading of (b): operators reach each DC's metal-admin; it is + not an argument for DC-to-DC management paths. + See F-CV3 in `docs/audit/queued-findings-20260806-phase03-coreverify.txt` for the live + dashboard-TLS defect this context bears on. + **VENDOR-DOCUMENTED REQUIREMENTS the build must honour** (researched 2026-07-31 against tailscale.com/kb and headscale.net; full citations in the session record): - **Tagged identity, not user identity.** Tailscale KB 1068: "it's more common for