From 23378c41b700c4373de4496b76eb399addfca68f Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Wed, 19 Aug 2026 12:00:00 +0000 Subject: [PATCH] docs(issues): #0088 - metadata egress blocked, and what that does not achieve 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 --- ...kpolicy-ausgehender-verkehr-ist-unbesch.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md b/docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md index 6ffa820..25ba7ab 100644 --- a/docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md +++ b/docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md @@ -87,3 +87,40 @@ Föderation, ACME, SMTP, Registry und der private Weg zu `10.0.0.3` bleiben offe schwierige Teil aus Punkt 4 des Issues wird damit gar nicht erst angefasst. Rollback bleibt das Löschen der einen Policy je Namespace. + +## Schritt 2 ausgerollt 2026-08-19 — Metadaten-Dienst gesperrt + +`egress-block-metadata` liegt in **matrix, authentik und monitoring** (Commit +`e7469a3`). Sie erlaubt DNS nach kube-system, die Cluster-Bereiche und `0.0.0.0/0`, +und sperrt allein `169.254.0.0/16`. + +**Abnahme in zwei Namespaces gemessen, nicht angenommen:** + +| Prüfung | matrix | authentik | +|---|---|---| +| DNS löst auf | ✅ | ✅ | +| Internet raus (matrix.org, HTTP 200 — die Föderation lebt) | ✅ | ✅ | +| Metadaten-Dienst | ✅ **blockiert** | ✅ **blockiert** | +| privates Netz `10.0.0.3:9090` | ✅ erreichbar | ✅ erreichbar | + +Alloy meldet seit dem Ausrollen **0 Fehlerzeilen** — der Weg nach `10.0.0.3` steht, +Metriken und Logs fließen weiter. + +**Ehrliche Einordnung des Gewinns:** Der Hetzner-Metadaten-Dienst gab hier +instance-id, hostname, region, MAC und Netzkonfiguration preis; `userdata` und +`public-keys` waren **leer**. Es lagen also keine Zugangsdaten offen, anders als im +AWS-Fall, auf den diese Härtung sonst zielt. Der Schritt schließt eine Klasse, er +verhindert keinen bekannten Angriffsweg. + +### Was dieses Issue offen lässt + +Der Kern der Forderung — **Default-Deny mit expliziter Freigabe** — ist damit **nicht** +erfüllt. Ausgehend darf weiterhin jeder Pod überall hin, außer ins Link-Local. Der +Grund steht in Schritt 1: Solange die Föderation offen ist (#0060), lässt sich Synapse' +Ziel-Menge nicht als Liste schreiben, und ein Egress-Proxy ist ein eigenes Vorhaben. + +Sinnvolle nächste Stufe wäre, **die Namespaces einzeln zu betrachten statt alle +gleich**: `monitoring` und `authentik` haben eine überschaubare, benennbare Ziel-Menge +(CFGMON privat, IONOS-SMTP, ACME) — dort ist Default-Deny realistisch. `matrix` ist es +wegen der Föderation nicht. Das Issue bleibt offen und trägt jetzt die Bestandsaufnahme, +die diese Entscheidung tragfähig macht.