Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 4515@bnt-lap001 Assistant-Session: 0bf96127-6e04-41be-bfda-d11717c3f354
3.4 KiB
3.4 KiB
King-path drill — post-event review record (NK-WP-0055-T13)
Value-free record. No token, share, key or OTP appears here or in any linked receipt.
| When | 2026-10-27/28 (UTC), founder workstation |
| Who | Founder (operator and authorizer); claude-code prepared commands and verified receipts |
| Why | Drill: prove that the final authority can act with SSO, KeyCape and OpenBao logins unavailable |
| Production touched | Only by the separate, earlier rollout of the loopback generate-root listener (RAPP-OPENBAO-WP-0003-T02). The drill itself ran on an isolated, networkless restore. |
Part 1: break-glass material from Storage Share
kingpath-offsite.py --verify fetched net-kingdom-kingpath-20261027T223050Z-8c9d48421f1b.tar.age
from the Storage Share Backup account. ETag, size and digest matched the upload receipt. An unrelated
key was refused, and the content decrypted in memory only. admin-kubeconfig (kubeconfig shape) and
tunnel-ssh-key (SSH private key header) were intact. The custody helper refused the custodian age key
until the railiance-backup key was entered, as designed. Crisis list item 1 was then split so the two
keys cannot be confused again.
Part 2: OpenBao break-glass on an isolated restore (RPF-WP-0064-T10)
- Run: attempt
RPF-WP-0064-T10-20261027-01, admissionsha256:741fa571…ce7a, adapter3727f8b, snapshotopenbao-raft-snapshot-rpf-wp-0015-t03-reboot-20261014-01-20261014t181053z.snap.age(plaintexta6312444…590b). - Result:
drilled(break_glass_drill_complete) in 101 s. The receiptsha256:e4591346e99b23e405f1cb69f6f5158dbdb7b5d69b2d1d7709c563a74cc18397stays outside Git and was independently verified (PASS) from a clean clone. - Held initial root token: valid as of the snapshot. It carries
rootpolicy, no TTL, no expiry, and is an orphan token. - Fresh
generate-root: the shares were re-entered and the OTP decode worked. The generated token carriedroot, the read-onlysys/authaction succeeded,revoke-selfreturned 204, and the follow-up lookup returned 403. - Cancel: a started attempt was cancelled cleanly.
- Teardown: the container was removed and verified absent, no volumes were created, the memfds were closed, and the readback credential was revoked.
Findings and follow-ups
- A standing, non-expiring root token very likely exists on production. It was valid at the
2026-10-14 snapshot and has not been revoked since. The architecture asks that the initial root token
be revoked, or escrowed as break-glass material. The
generate-rootpath now works on production and is drilled, so it can replace that token. Founder decision7ce684ec: keep it escrowed during builder mode and revoke it at production entry (NK-WP-0055-T16, guarded script in railiance-platform95b5a19). - Production read-only SSO-down walk: passed on 2026-10-28. It went through the static-key tunnel and the admin
kubeconfig.
openbao-0was Running, OpenBao 2.5.4 was unsealed with threshold 2 of 3, the break-glass listener 8210 answeredgenerate-rootstatus 200 and the main listener 405. Nothing was changed. - Admission signing key: it is
~/.ssh/gexec_approver_ed25519. The founder stored a copy in the password safe under the kingpath entry on 2026-10-28 (crisis list item 5). - Not drilled: using the restored kubeconfig and SSH key against the cluster. Provider console access is not drilled either.