net-kingdom/docs/evidence/2026-10-28-king-path-drill.md
tegwick 7384007256
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 4s
NK-WP-0055-T13: done; king path drilled and production SSO-down walk passed
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
2026-10-28 01:04:29 +01:00

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, 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.