65 lines
3.4 KiB
Markdown
65 lines
3.4 KiB
Markdown
# 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.
|