Rolled out to matrix, authentik and monitoring, verified in two namespaces rather
than assumed: DNS resolves, federation still reaches matrix.org, the metadata service
is blocked, and the private path to 10.0.0.3 is intact with Alloy reporting no errors.
The issue stays open on purpose. Its actual demand - default deny with explicit
allows - is not met; egress is still open everywhere except link-local. Federation
makes that unwritable as a list while it stays open (#0060). What is now on record is
the inventory that makes the next decision possible: monitoring and authentik have a
nameable set of destinations and could take default deny, matrix cannot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Before anything else: NetworkPolicy really is enforced here. k3s runs flannel and the
policy controller inside its own process, so the absence of pods in kube-system
proves nothing - measured instead, with a counter-probe. synapse-main reaches
matrix's postgres and authentik-server does not, exactly as allow-ingress-postgres
says. So the existing ingress rules are real protection and egress rules will bite.
The textbook first step - allow 0.0.0.0/0 but except RFC1918 and the metadata
service - would have cut two things here, both over 10.0.0.3, CFGMON on the private
Hetzner network. Alloy remote-writes metrics and logs there, so monitoring would have
gone silent, and nothing reports the failure of the reporting path. And the TURN
rotation reaches Gitea through a hostAlias to that address because the public route
was unreliable, so the rotation push would have died a day after we got it working
again.
That also settles #0008 harder than the absence of a firewall rule could: the cluster
reaches Prometheus and Loki privately, so 9090 and 3100 are demonstrably not needed
publicly.
Proposed step 2 is therefore narrower and nearly risk-free: block only the metadata
service, 169.254.0.0/16, while leaving federation, ACME, SMTP, registries and the
private path open. Nobody here needs the metadata service, and the hard part of this
issue - federation to arbitrary servers - is not touched at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ADR-0012 made docs/issues/ canonical for the management scope only and left
gitops, ThreadNet-Web and threadnet-call on GitLab "until the component adopts".
That split produced exactly what it invited: two numbering worlds where
management#20 and gitops#20 are different issues, drift nobody had to answer for
(gitops#61 carried no milestone since 2026-08-11), and component backlogs that
host sessions without lab access cannot read at all.
The 46 open component issues are now files 0056-0101. The file id is the
group-wide identifier; provenance lives in the frontmatter (new field `projekt`
plus gitlab_iid) and in the filename, so "gitops#61" still finds 0091. Bodies are
copied verbatim; comments and history stay on GitLab, as with the 2026-08-11
management import.
Both scripts learned the second dimension: spiegel_issues.py routes each file to
its origin project, reopens issues that are open in the repo but closed on the
board, and writes the new iid back after creating one; gruppenpruefung.py checks
drift across all four trackers instead of management alone. What the mirror
cannot decide stays a finding, not a silent state.
Two things needed a hand, both recorded in the files: gitops#61 had no milestone
(M1 - it is a live account-takeover path) and carried two area labels where the
schema holds one. The Gitea migration footers in the imported bodies point at
decommissioned trackers; their links are removed, the provenance sentence stays.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Thore CimbalandClaude Opus 5