chore(docs,nix): fix stale 'localhost via shared netns' claims in forge/matrix

Agents in private netns can't reach host loopback directly; they
use forge.<domain> and matrix.<domain> via the gateway. Update four
locations that still claimed direct loopback access:

- hive-forge.nix: module header + openFirewall description
- hive-matrix.nix: openFirewall description
- docs/matrix.md: container design bullet + openFirewall section
This commit is contained in:
atlas 2026-07-04 21:10:47 +02:00 committed by mara
commit 23f13d9e71
3 changed files with 14 additions and 15 deletions

View file

@ -17,10 +17,9 @@ Same shape as [`gateway.md::hive-forge container shape`](gateway.md):
operator already runs on the host — separate systemd namespace,
separate state dir.
- Container shares the host network namespace
(`privateNetwork = false`) so agents reach tuwunel at
`http://localhost:<httpPort>` without extra plumbing — the
nixos-container is here for state + systemd-unit isolation, not
network isolation.
(`privateNetwork = false`) for state + systemd-unit isolation. Agents
reach the homeserver at `matrix.<domain>` via the gateway (agents
run in private netns and can't access host loopback directly).
- Persistent state at
`/var/lib/nixos-containers/hive-matrix/var/lib/matrix-tuwunel/`
survives container restart / host reboot. To wipe, destroy the
@ -52,9 +51,9 @@ sub-domain from the user-facing identifier.
## Default-closed firewall
`openFirewall` defaults to `false` (secure-by-default): the
homeserver is reachable from the host + every agent container via
loopback either way (shared netns), so the firewall hole only
`openFirewall` defaults to `false` (secure-by-default): the host
reaches the homeserver on loopback, and agent containers reach it
at `matrix.<domain>` via the gateway — so the firewall hole only
matters for access from *outside* the host. Flip to `true` when
announcing the homeserver to other hives or when an external matrix
client needs to reach the client-server API directly.