net-kingdom/docs/nk49-phase-b-plan.md

NK49 phase B: isolated KeyCape and restored OpenBao on one internal network

NK-WP-0049-T43. Drafted 2026-10-24. Preparation only. This grants no authority, starts nothing and is not T18 acceptance. Every number marked proposed is a suggestion for the owners, not a fact.

Purpose

T18 needs a live consumer login against restored dependencies. The consumer is secrets-engine's secrets-engine-openbao workload (SECRETS-WP-0015-T04): it obtains a token from KeyCape, then logs in to OpenBao with the JWT role. Today the two recovered pieces cannot meet:

Piece	State	Network today
Isolated original KeyCape (NK49 T18 attempt)	Verified 2026-10-23, receipt 16d72f7c…1651, then destroyed	--network none; TLS served on its own loopback
Restored original OpenBao (RPF-WP-0064-T07)	Verified 2026-10-24, receipt 4e048dee…579d, then destroyed	--network none; listener on 127.0.0.1:8200 only

OpenBao's keycape-services JWT auth validates against https://kc.coulomb.social/jwks. A networkless OpenBao proves configuration but cannot perform the login. Phase B is the shared network that lets it.

Proposed topology

        docker network create --internal   (no gateway, no published ports)
  ┌───────────────────────────────────────────────────────────────────────┐
  │  keycape-worker   alias kc.coulomb.social   :443 TLS ─▶ issuer :8080  │
  │  (+ issuer sharing its namespace, as in the T18 attempt)              │
  │                                                                       │
  │  restored OpenBao   alias bao-restored   :8200 (unsealed, same window)│
  │                                                                       │
  │  consumer runner    (secrets-engine owned; the only client)           │
  └───────────────────────────────────────────────────────────────────────┘
        no other attachment · egress shown refused before admission

Who owns what

Step	Owner	Notes
Create and tear down the internal network	Proposed: railiance-platform	Its design stub already says phase B is "a single docker network create --internal network". One creator avoids a double teardown.
Restore and unseal original OpenBao, keep it up for the window	railiance-platform	Adapter runs phase A, then does not tear down when phase B is admitted in the same window (its doc). Needs a listener on the internal address, not loopback only.
Start the isolated original KeyCape on that network	NetKingdom (this plan)	Needs a new variant of the T18 machinery; see below.
Consumer login: KeyCape exchange, OpenBao JWT login, openbao:admin refusal, session revocation	secrets-engine	SECRETS-WP-0015-T04.
ACME issuance for kc.coulomb.social	railiance-cluster	Existing owner of the T33 reissue.
Window, abort, and every signature	founder	One window, several admissions.

What NetKingdom must change (verified from current source)

The T18 machinery is pinned: prepare-isolated-keycape.py lists isolated-keycape.py, isolated-keycape-session.py, run-isolated-keycape.sh, isolated-lldap.py, identity-bundle.py, verify-identity.py and others as the reviewed source closure, and the T38 review and T40 admission bind their hashes. They must stay unedited. Phase B is therefore a new module beside them, with its own review.

Facts read from the code that force changes:

1. isolated-keycape-session.py launches the worker with --network none and --add-host kc.coulomb.social:127.0.0.1. Phase B needs the worker on the internal network with --network-alias kc.coulomb.social.
2. isolated-keycape.py inspect_session refuses any worker whose NetworkMode is not none, and checks that dependent containers have container:<worker>. A phase B variant must accept exactly one named internal network and verify, by inspection, that it is Internal=true, that its attached set is exactly the admitted containers, and that the worker has a subnet route but no default route.
3. The probes assert that only lo exists and /proc/net/route has one line. In phase B an interface and a subnet route exist by design, so "no external route" must be proved differently: no default route, Internal=true, and refused egress probes (to a public address and to a name outside the admitted aliases).
4. verify-keycape-attempt-receipt.py expects the none topology and must have a phase B counterpart, so the receipt can still be verified independently.
5. The T40 admission window ended 2026-10-24T05:00Z. Phase B needs a new founder signature; nothing signed before carries over.

Proposed new files (names are suggestions): isolated-keycape-phase-b.py, run-isolated-keycape-phase-b.sh, verify-keycape-phase-b-receipt.py, tests, and a packet section. Effort is moderate to large and touches the most sensitive machinery here, so it should get the same review depth as T38, not a quick patch.

Preconditions and ordering (proposed)

1. Owners each pass their own preflight (RPF-WP-0064 adapter, the secrets-engine selector with --admission, NK49 prepare-style validation).
2. One founder window, at most 24 h (owner admission rules). OpenBao's own deadline is 45 minutes from its first custody input, so OpenBao is started last among the long-lived pieces and the consumer run follows immediately.
3. railiance-platform creates the network and shows egress refusal.
4. NK49 starts the isolated KeyCape (age key, TLS key and trust in the founder's terminal, as in the T18 ceremony).
5. railiance-platform restores and unseals OpenBao onto the same network.
6. secrets-engine runs the consumer login.
7. Teardown in reverse; each owner returns a safe receipt. The network creator removes the network last and shows it gone.

Evidence and claims

Returned: NK49 phase B receipt (verified independently), railiance-platform's phase B receipt, secrets-engine's consumer result. Together they would show, with no secret values: the original issuer and signing key served over TLS on the internal network; openbao:login accepted; openbao:admin refused; wrong secret refused; a session revoked; egress refused; cleanup of containers, tmpfs and network.

Not claimed: production continuity or redirect, new grants, a live OpenBao read of secret data (platform/workloads/keycape/secrets-engine-openbao stays metadata only), human login through Authelia, or owner acceptance. T18 also needs its owner acceptance.

Decisions (answered 2026-10-27; decision e4db6c9f) and remaining owner items

Founder answers: 1 railiance-platform creates the network; 2 reissue via letsencrypt-prod once railiance-cluster confirms the duplicate count (no self-signed, no retained key); 5 one workload consumer suffices, no Authelia. Item 3 (secret custody) is secrets-engine's to propose and item 4 (ISRG trust) is confirmed in the owner rehearsal. The answers authorize nothing; windows and signatures stay separate.

1. Network creator. railiance-platform (proposed) or NetKingdom?
2. TLS identity. The T18 attempt reissued kc.coulomb.social through letsencrypt-prod and destroyed the key. Phase B needs a certificate again: reissue (consumes the duplicate-certificate allowance, limit 5 per week; railiance-cluster should confirm the count) or retain the key from the earlier attempt (a custody decision). No self-signed substitute is allowed (decision 9f9d0d88).
3. Consumer secret custody. The consumer's client secret keycape-secrets-engine-openbao-client is in the backup's KeyCape secrets. How does the consumer runner receive it without the agent, argv or files seeing it? This is secrets-engine's design to propose; NetKingdom must not hand it over implicitly.
4. Trust in OpenBao. The restored OpenBao must trust the ISRG Root X1 chain to fetch /jwks. Confirm in the owner's rehearsal rather than assume.
5. Scope. Is this one workload consumer enough for T18's "selected current consumer", or must a human-login consumer also be admitted? This plan assumes the workload consumer and does not require Authelia in phase B.

Unsigned admission

docs/nk49-phase-b-admission.example.json is a template with placeholders. It is not signed, names no real hashes for unwritten files and authorizes nothing.