codex
86209c756c
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
5.1 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated | related | origin | origin_ref | state_hub_workstream_id | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RPF-WP-0027 | workplan | Coordinate KeyCape live Secret exposure recovery | financials | railiance-platform | active | codex | railiance | 2026-08-23 | 2026-08-23 |
|
routed | State Hub messages e88abb61-e393-4a82-817c-5ac378a2ee3d, acf98be3-ff6b-4270-bd21-0193bebd806b, aeb216b5-9f1b-404b-a483-fb08a00a49b1, and 71b1008a-7fd7-4500-85c6-e8893a6d80d4 | b2c25a01-4a80-55c1-90cf-8538000f7e0e |
RPF-WP-0027 — KeyCape live Secret exposure recovery
Goal
Coordinate a forward-only, value-safe rotation of every credential class in
the exposed sso/keycape-config bundle. Never reproduce or decode the exposed
payload and never treat repository access as live mutation authority.
T01 — Contain and establish the recovery boundary
id: RPF-WP-0027-T01
status: done
priority: high
state_hub_task_id: "53f47272-92ab-563b-9d69-5eafee733e6b"
Accepted the KeyCape/NetKingdom incident reports, stopped payload inspection,
and routed custody through warden route show openbao-api-key. Metadata-only
preflight pinned Secret UID/resource version, Deployment generation/image, and
the public JWKS digest/kid. The legacy value-printing rotation helper is banned.
T02 — Publish the governed bundle cutover
id: RPF-WP-0027-T02
status: done
priority: high
state_hub_task_id: "3c55b1cd-8f6b-5a48-b416-18ab711954e3"
docs/keycape-live-secret-exposure-recovery.md defines owners, required
revision/window/operator receipts, private-file handling, one guarded bundle
apply, provider/consumer ordering, forward-only abort, positive/negative proof,
predecessor revocation, and sanitized evidence.
T03 — Collect exact owner acknowledgements
id: RPF-WP-0027-T03
status: progress
priority: high
state_hub_task_id: "714ae011-903d-55e2-ac47-801b8ef879d1"
KeyCape supplied source revision 93704fd2424503007c20b458b62a7f7d994bb288,
post-rotation JWKS SHA-256
c6faac5dfeef2453daf9cfc14671f62b535dd321befdf6014e3ee5c2cf1f1156, and
rollout/predecessor evidence (messages 05b49688-76a8-4be9-a00d-95408c798697
and 538046b9-2dbb-4704-b7b6-2dbf16c5e3bb). NetKingdom pinned the value-safe
dependency and provider sequence at c24d67b (message
71b1008a-7fd7-4500-85c6-e8893a6d80d4). The persistent privacyIDEA
lldap-coulomb resolver still requires an attended provider-admin update, so
T04 remains blocked for that explicit follow-up. The digest-bound approval
template is published at
docs/keycape-exposure-rotation-approval.example.json; no additional Secret
apply is authorized by this receipt.
NetKingdom has now pinned the remaining attended resolver procedure at
eec7007 (procedure checkout f2e578c, owner receipt
45b236c8-052f-43d3-a472-44f8e9694da2). It performs one resolver-only POST,
protected interactive inputs, boolean postchecks, replacement-success and
predecessor-denial evidence, and forward-only abort. T03 is ready for the
attended run; T04/T05 remain open until that run produces a sanitized receipt.
The operator completed the resolver-only update and received
privacyIDEA resolver update: PASS. Postchecks were not yet run; the operator
was instructed to stop rather than improvise. NetKingdom has been asked to
package the complete sequence as one receipt-producing command for the next
run.
The Railiance-side custody contract is drafted at
docs/net-kingdom-credential-custody-contract.md. It deliberately leaves the
OpenBao path and field names unfilled pending owner confirmation; the routing
lane remains unresolved and no credential fetch or retry is authorized.
T04 — Execute the attended rotation
id: RPF-WP-0027-T04
status: wait
priority: high
state_hub_task_id: "28b31e57-7a76-5100-8a61-9aa87339c5d7"
Requires a fresh exact human GO, an at-most-30-minute window, named driver and abort operator, approved revisions, provider access, private workspace cleanup, and all T03 acknowledgements. No value may enter captured output.
T05 — Prove predecessor denial and close
id: RPF-WP-0027-T05
status: wait
priority: high
state_hub_task_id: "9cb5fa67-012a-58cf-bafb-e7c7d4f9782d"
Verify replacement operation and predecessor rejection for the signing key, LLDAP binding, Authelia client, and privacyIDEA token. Retain only safe fingerprints, resource versions, public JWKS metadata, boolean results, rollout status, timestamps, and cleanup receipts.
T06 — Publish the Railiance/OpenBao custody handoff
id: RPF-WP-0027-T06
status: progress
priority: high
state_hub_task_id: "3b9748c4-2906-5ba7-9d34-0a7067a59283"
The platform/OpenBao owner must publish a non-secret receipt for both routing
lanes: canonical mount/path, field name, KV version semantics, least-privilege
policy and auth method, expiry/rotation/revocation semantics, and the approved
attended handoff identifier. Do not infer or invent any of these values. After
publication, update docs/net-kingdom-credential-custody-contract.md, ask
ops-warden to refresh lane resolvability, and pass only protected inputs to
NetKingdom's minimal resolver reconciliation flow.