# 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](../../railiance-master/docs/adr/ADR-0008-private-by-default-exposure.md).
`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.