net-kingdom/docs/crisis-custody-list.md
tegwick 6d4acb0ca9
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
NK-WP-0055-T13: retire the ops bundle; root-token check joins the king-path drill
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-27 23:13:13 +01:00

6.6 KiB

Crisis custody list

NK-WP-0054-T07. Drafted 2026-10-24 from repository documents and the founder's statements that day. This list holds no secret value, ever. It names what unlocks recovery, who holds it, where, and whether using it needs the very services being recovered. Anything the repository cannot establish is marked TO CONFIRM; the founder confirms each one.

It belongs with the backup documentation: disaster recovery guide, identity restore drill and Credential Management Standard §4. That standard names the custody categories. This list makes them concrete.

The one rule

For every row, answer: does using this item work when SSO and OpenBao are down? A recovery path that is satisfied only by logging in to something being restored is a circular dependency and is recorded as a gap, not as custody.

Roles used below

Role Identity Used for
Crisis operator admin Runs recovery and routine validation (founder intent, 2026-10-24)
Authorizer platform-root / king credential Break-glass authority from offline custody; nothing routine
Developer tegwick Builds and tests tooling; holds no recovery keys

Items

# Item Unlocks Holder and location Works with SSO and OpenBao down? Last proven use Gap or action
1 Custodian/backup age private key (recipient age1zvry…50syr3tsz, labelled railiance-backup) Decrypts the identity backup bundle and the SOPS custody files Founder, independently held password safe or offline packet (Standard §4) Yes, offline Entered by the founder at hidden prompts 2026-10-24 (LLDAP, Authelia, privacyIDEA stages) TO CONFIRM: number of copies, who else could recover if the founder cannot
2 Storage Share Backup account app password Downloads the protected ciphertext without OpenBao or SSO Founder, independent custody TO CONFIRM Yes, provider is outside the platform Fresh retrieval 2026-10-24 One provider copy only; residual risk accepted until 2027-01-31 (G1, NK-WP-0053)
3 OpenBao unseal shares (2 of 3 required in the restore drill) Unseals a restored or production OpenBao; with the shares, generate-root can mint a root token for break-glass (ceremony not yet documented) Founder as platform-root holds all three shares (single-holder custody: accepted exception, hub decision 37464824, 2026-10-27), in the founder's replicated browser password safe under the kingpath.credentials pseudo-URL entry (confirmed 2026-10-27) Yes: the safe is independent of NetKingdom SSO and OpenBao; it depends on the browser vendor's sync account and its own factor Original shares used in the isolated restore RPF-WP-0064-T07, 2026-10-24 Single holder = single point of loss (reviewed at NK-WP-0055-T09). The founder holds the initial root token offline (2026-10-27); its validity is checked in the king-path drill (NK-WP-0055-T13) against an isolated restored OpenBao, never production
4 platform-root / king account and factors Final authority; break-glass Independently held password safe or offline packet (Standard §4; custody doc) No if used through KeyCape: its login and OTP are validated by the services being recovered OTP validated against restored privacyIDEA 2026-10-24 (isolated) TO CONFIRM the offline path that works with SSO down (OpenBao shares, item 3) and record it
5 Founder admission signing key (SSH, principal bernd) Signs attempt and restore admissions Founder, workstation key; verifier anchor /etc/secrets-engine/admission/allowed_signers Yes Signed the T40 admission 2026-10-23 TO CONFIRM which identity this key belongs to; the anchor is workstation-bound, so a backup of key and anchor is needed
6 admin password and OTP token Day-to-day platform administration and, per intent, recovery operation Founder; OTP enrolled 2026-10-24 No: login and token checks need KeyCape, LLDAP and privacyIDEA Token not yet in any restored backup; first restore proof after the 2026-10-25 03:45 UTC capture Same account as the directory bind used by Authelia and privacyIDEA until the split in NK-WP-0054-T05
7 pi-admin credentials (privacyIDEA internal admin) Token repair and re-enrolment Founder's replicated browser password safe (confirmed 2026-10-27) Custody yes (replicated, independent of SSO); use needs a running privacyIDEA Not yet drilled Add a pi-admin check to the drill (NK-WP-0053-T04)
8 Ops bundle (make creds-bundle) Retired 2026-10-27 (founder decision) — — — Never drilled; none existed on the workstation Superseded by the daily identity backup, which carries the current service secrets. make creds-bundle packs only greenfield creds-generate output and stays a greenfield bootstrap step
9 Operator access to the production host or cluster for a real restore Applying a restore to production Cluster: ops-bridge tunnel k3s-api-railiance01 (SSH as tegwick to 92.205.62.239 with a static key file, local port 16444) plus the attended admin kubeconfig ~/.kube/config-railiance01 (client certificate), today on the founder workstation only. Host: Host Europe provider interface with console and rescue access to railiance01 (confirmed 2026-10-27) Yes: static key, client certificate and provider console need neither KeyCape nor OpenBao. No for ops-warden SSH certificates (warden's backend is OpenBao) Cluster path used 2026-10-27 Founder decision 2026-10-27: an age-encrypted copy of the cluster break-glass material goes to the Storage Share Backup account so it survives workstation loss (NK-WP-0055-T13). Open: runs as tegwick under an agent-labelled actor; provider console never drilled

Non-secret recovery assets

These need no custody but must be reachable: the published recovery kit on Storage Share (guide, tools ZIP, checksum; verify the checksum against a trusted copy), the pinned container images, and a trusted checkout of this repository. TLS for kc.coulomb.social has no custody: it is reissued through ACME and needs working public DNS and HTTP-01.

Maintenance

  • Review at every restore drill (NK-WP-0053), and record the date each item was last proven. An item never proven stays marked as such.
  • Loss or suspected exposure of any item goes to its owner's rotation and revocation process (Standard §6); this list rotates nothing.
  • A machine-readable, non-secret record with a freshness check, modelled on tools/custody-record, is proposed in NK-WP-0054-T07. Until then this document is the list.