the-custodian/docs/inner-zone-access-without-a-company-network.md

Open question: reaching the inner management zone without a company network

Status: open, parked deliberately. Not scheduled, not assigned. Raised by: the founder, 2026-09-23, out of the bao.coulomb.social retraction. Touches: railiance, net-kingdom, helixforge, coulomb. Owner when picked up: railiance-master (exposure posture, ADR-0008) with net-kingdom (identity and assurance).

This file exists so the tension is written down, not solved. Do not treat anything here as a decision.

The tension

Management surfaces — the OpenBao UI, the k3s API, ArgoCD, the State Hub — are private or operator under ADR-0008. operator means the listener stays unpublished and reachable only through a named ops-bridge/SSH tunnel. That is a good posture for a secret store, and on 2026-09-15 it is why the public OpenBao listener was retracted (RMASTER-WP-0020-T09, closed as railiance-platform RPF-WP-0025-T03).

It also assumes something this estate does not have: a classic company network. The tunnel model quietly requires a device carrying an SSH certificate and an ops-bridge setup. The real operating model is remote, bring-your-own-device, and includes collaborators who are not company staff and never will be. Those two facts pull against each other:

• Posture pull: an internet-reachable login form in front of the estate's credentials is a standing invitation. Requiring a certificate before the form is even visible removes a whole class of attack.
• Access pull: an operator on a phone, a tablet, a fresh laptop, or an external collaborator on their own device cannot reach a management surface at all. The workaround is to provision another SSH-carrying device, which is exactly the company-network assumption re-entering through the back door.

Neither pull is wrong. Today the second one loses by default, because private is the default posture and there is no considered answer for BYOD access.

What a later answer has to cover

• Identity and device assurance strong enough to replace "is on the network": what net-kingdom can already assert (IAM Profile claims, AAL, factor state) and what it cannot.
• Whether a device must be enrolled at all, and what an unenrolled device may reach. Enrolment is itself a company-network assumption if made mandatory.
• Non-company collaboration: guests reaching a bounded surface without becoming operators, and without a membership implying authorization (the user-engine boundary rule holds here too).
• Whether the answer is per-surface exposure grants under ADR-0008, an identity- aware proxy in front of operator surfaces, or something else. This note does not choose.
• Break-glass: what works when ops-bridge is down. Note that the cluster generally needs SSH in that situation anyway, so the gap may be narrower than it looks.
• Seeding: how a brand-new zone gets its first trusted operator before any of this exists.

Not blocked on this

The retraction stands. The OpenBao UI is unchanged and reachable through the openbao-ui-railiance01 tunnel at http://127.0.0.1:18200/ui/; nothing was made headless. Separately, bao.coulomb.social now serves a plain "not publicly available" page on a trusted certificate instead of a self-signed TLS error (railiance-platform RPF-WP-0047, live 2026-09-23, verified from outside 2026-09-24). That closed the broken-looking surface; it did not answer this question.