tegwick
7384007256
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
51 lines
3.4 KiB
Markdown
51 lines
3.4 KiB
Markdown
# 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`, admission `sha256:741fa571…ce7a`, adapter `3727f8b`,
|
|
snapshot `openbao-raft-snapshot-rpf-wp-0015-t03-reboot-20261014-01-20261014t181053z.snap.age`
|
|
(plaintext `a6312444…590b`).
|
|
- **Result:** `drilled` (`break_glass_drill_complete`) in 101 s. The receipt
|
|
`sha256:e4591346e99b23e405f1cb69f6f5158dbdb7b5d69b2d1d7709c563a74cc18397` stays outside Git and was
|
|
independently verified (`PASS`) from a clean clone.
|
|
- **Held initial root token:** valid as of the snapshot. It carries `root` policy, 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
|
|
carried `root`, the read-only `sys/auth` action succeeded, `revoke-self` returned 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
|
|
|
|
1. **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-root` path now works on production and
|
|
is drilled, so it can replace that token. Founder decision `7ce684ec`: keep it escrowed during builder mode and
|
|
revoke it at production entry (NK-WP-0055-T16, guarded script in railiance-platform `95b5a19`).
|
|
2. **Production read-only SSO-down walk:** passed on 2026-10-28. It went through the static-key tunnel and the admin
|
|
kubeconfig. `openbao-0` was Running, OpenBao 2.5.4 was unsealed with threshold 2 of 3, the break-glass listener
|
|
8210 answered `generate-root` status 200 and the main listener 405. Nothing was changed.
|
|
3. **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).
|
|
4. **Not drilled:** using the restored kubeconfig and SSH key against the cluster. Provider console
|
|
access is not drilled either.
|