jschoubben
4279e4914b
One green fresh run of the no-fake two-node bed is the proof: node2's consumers open the store and broker the mesh built and adopted, over the overlay. Fixed by mesh-controller PR 29, mesh-catalog PR 26, gated by mesh-lab PR 34.
81 lines
4.2 KiB
Markdown
81 lines
4.2 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-14
|
|
located-in: [mesh-controller, mesh-catalog]
|
|
fixed-by: mesh-controller PR 29 (98aea8b); mesh-catalog PR 26 (1891b09); gated by mesh-lab PR 34
|
|
amended-design: 02-DECISIONS/0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md
|
|
---
|
|
|
|
# 048 — Nothing makes a machine trust the mesh's own registry
|
|
|
|
## Symptom
|
|
|
|
The registry module says, in its own manifest, that its port is open to the mesh because *every
|
|
machine pulls images and artifacts from here*. A machine that tries to do so is refused by its
|
|
container runtime before the mesh is involved at all: the registry serves plain HTTP, and a
|
|
container runtime treats any registry that is not loopback as HTTPS.
|
|
|
|
Nothing in the mesh arranges otherwise. There is no resource that configures a runtime's view of
|
|
the registry, no field in a manifest for it, and no step in joining that establishes it.
|
|
|
|
**It has never failed, and the reason it has never failed is the finding.** Every proof that a
|
|
machine can fetch a mesh-built artifact has been a proof about the machine that built it, where the
|
|
reference was loopback and loopback is trusted by default. The one bed that pushes to a routable
|
|
address gets away with it because *the lab* writes the runtime's configuration before the mesh is
|
|
raised, naming the documentation ranges its scenarios use. That file is the lab's, not the mesh's,
|
|
and no machine outside a bed has one.
|
|
|
|
Observed while fixing a neighbouring fault: the builder recorded artifacts under a loopback address
|
|
(fixed — the binding states where the provider is, and it now uses it). Correcting the address is
|
|
what makes this reachable, and therefore what makes this visible.
|
|
|
|
## Why this matters
|
|
|
|
**A stated rule is enforced by nothing.** The registry declares that the whole mesh pulls from it
|
|
and opens a port to the mesh accordingly. That is the design. Whether any machine can act on it
|
|
depends on a file the mesh does not write, does not read, and has no opinion about.
|
|
|
|
**It is the other half of [042](../042-nothing-gives-a-node-an-account-for-a-registry/00-report.md),
|
|
and the two are easy to confuse.** 042 is about a machine not being *allowed* to pull — no
|
|
credential. This is about a machine not being *able* to, regardless of credential, because the
|
|
transport is refused. A fix for 042 alone would leave a machine holding a valid account for a
|
|
registry its runtime will not talk to, which fails with an error about certificates and reads as a
|
|
credential problem.
|
|
|
|
**It decides something about the private network that has not been decided.** Serving artifacts
|
|
over plain HTTP is defensible if the private network is the boundary, and indefensible if it is
|
|
not — and either way it is a position, not an omission. Today it is an omission that happens to
|
|
work in one place.
|
|
|
|
**It is a joining problem before it is anything else.** The first machine never meets it. Every
|
|
machine after it does, on the first module the mesh built rather than fetched — which is most of
|
|
them.
|
|
|
|
## Evidence
|
|
|
|
A machine raised by the installer, asked what its runtime trusts:
|
|
|
|
```
|
|
Insecure Registries:
|
|
127.0.0.0/8
|
|
<the documentation ranges this lab uses>
|
|
::1/128
|
|
```
|
|
|
|
Everything but the loopback entry was written by the harness. The mesh contributed none of it.
|
|
|
|
## Open questions
|
|
|
|
- **Should the mesh's registry serve TLS?** It would make the transport a property of the registry
|
|
rather than of every machine that talks to it, and the mesh already issues certificates. What
|
|
signs it, and what a machine checks it against, are the real questions.
|
|
- **Or should a machine's runtime be configured by the mesh** — a resource that states what this
|
|
machine trusts, applied like any other? That puts a node-wide setting in a module's hands, which
|
|
may be the wrong ownership.
|
|
- **What is the boundary the answer assumes?** If plain HTTP inside the private network is
|
|
acceptable, that assumption should be recorded with what it takes for granted about who is on
|
|
that network — and checked, rather than inherited from a harness.
|
|
- **How does this interact with genesis?** The installer publishes before the mesh can grant or
|
|
configure anything, and gets away with loopback. Whatever is decided has to leave that moment
|
|
workable.
|