The RAILIANCE-WP migration numbered from RPF-WP-0001 without checking whether the target prefix was already in use. It was: this repository already had RPF-WP records, and the migration collided at 0018, 0019 and 0020, putting two unrelated workplans on each identifier. Central was left holding mixed records — rpf-wp-0018 carried the status of one file and the backing path of the other, because the reset processed two files claiming one identifier. The three files the migration displaced move to 0025-0027; the pre-existing records keep their numbers. Projection UUIDs are re-derived. Refs STATE-WP-0083-T05 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2583210@bnt-lap001 Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
3.1 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated | related | state_hub_workstream_id | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RPF-WP-0025 | workplan | Retract public OpenBao listener behind operator-only access | financials | railiance-platform | blocked | codex | railiance | 2026-08-23 | 2026-08-23 |
|
6dda6039-295e-5cac-aef6-3183c3218649 |
RPF-WP-0025 — OpenBao operator-only access
Goal
Implement the S3-owner half of RMASTER-WP-0020-T09 without coupling it to destructive CoulombCore cleanup.
T01 — Align the retained compatibility source
id: RPF-WP-0025-T01
status: done
priority: high
state_hub_task_id: "80f9638f-707f-5038-bc77-5962b535949e"
The retained platform manifest now matches the canonical package posture: Deployment plus ClusterIP Service only. Ordinary deploy no longer applies the public-only middleware. The old Ingress remains solely in an explicitly named rollback artifact.
T02 — Add guarded retraction and rollback
id: RPF-WP-0025-T02
status: done
priority: high
state_hub_task_id: "685aba0f-2594-5b99-903a-8c9cd16f6539"
scripts/openbao-public-listener-transition.sh pins the cluster UID, verifies
source and runtime packet posture, requires a lifecycle-healthy named tunnel,
and gates live deletion on exact confirmation plus attended-login verification.
It deletes only the Ingress and provides an exact rollback path.
T03 — Complete the attended operator cutover
id: RPF-WP-0025-T03
status: wait
priority: high
state_hub_task_id: "8850d742-7cd7-5a1b-ba52-4dbc4bdeba7e"
KeyCape revision d150be1 now admits exactly
http://127.0.0.1:18200/ui/vault/auth/netkingdom/oidc/callback in the
source-owned openbao-admin client and pins it in configuration tests. The
OpenBao auth/netkingdom/role/platform-admin role must still independently
admit that exact callback, and an attended MFA login must pass. The
host-namespace preflight already proves openbao-ui-railiance01
lifecycle-healthy and reaches the expected overlay. Then execute the guarded
retraction, coordinate public DNS withdrawal with railiance-infra, and return
non-secret acceptance evidence to Railiance Master.
Net Kingdom revision 61aeafe additionally applied the exact KeyCape callback
live and proved the public authorization endpoint accepts it. Railiance
Platform now carries the silent, narrowly scoped
scripts/openbao-apply-operator-loopback-callback.sh owner command for the
governed openbao-platform-admin-login lane. The remaining hold is one
attended OIDC/MFA execution of that command followed by one loopback UI login.
An attended attempt on 2026-08-23 failed closed before command handoff. Warden
contained all login output and did not execute the role update; its cleanup
could not confirm self-revocation, so the attempt is terminal NO-GO and must
not be treated as callback evidence. No public-listener or OpenBao role change
was made. T03 remains wait for a fresh attended execution after the operator
is ready to complete the browser/MFA act.
This workplan authorizes no OpenBao seal/unseal, policy broadening, PVC or Secret mutation, reboot, restore, or RMASTER-WP-0020-T08 cleanup.