From 897755cdef32927e2ebf995f9912c935ec7bfb7b Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Thu, 20 Aug 2026 12:00:00 +0000 Subject: [PATCH] #0088: zehn Arbeitslasten dicht, mit Abnahme Sperre beisst (wikijs-postgres und element-web-docs erreichen weder Internet noch CFGMON), erlaubte Pfade funktionieren (DNS, Pod zu Postgres), breite Pods sind unberuehrt (synapse erreicht rohana, CFGMON und 1.1.1.1). Zwei eigene Fehlmessungen dokumentiert, weil sie wiederkommen: 10.43.0.1:443 ist auch aus einem Pod mit breitem Ausgang nicht erreichbar, und /dev/tcp gibt es in dash nicht - im Synapse-Container meldet es immer Fehlschlag. Korrektur zur Zaehlung: zehn, nicht neun. Nebenfund aus sorbs Frage zur URL-Vorschau: Synapses eigene Sperrliste enthaelt 169.254.0.0/16 nicht - heute durch die NetworkPolicy gedeckt, beim Umbau des Egress-Modells aber nachzutragen. --- ...kpolicy-ausgehender-verkehr-ist-unbesch.md | 57 +++++++++++++++++++ 1 file changed, 57 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 37882e9..3cc7091 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 @@ -228,3 +228,60 @@ Metadaten-Sperre ergibt sich dann von selbst, weil nichts mehr pauschal erlaubt ⚠️ Alle Zuordnungen oben sind **aus Konfiguration und Aufgabe abgeleitet, nicht gemessen**. Vor jedem Schnitt gehört geprüft, wohin der Pod tatsächlich spricht — sonst tauscht man eine offene Flanke gegen einen stillen Ausfall. + +## Umgesetzt 2026-08-20 — zehn Arbeitslasten ohne Ausgang nach draußen + +Entscheidung sorb. Umgesetzt in `gitops:a6eaea6`. (Korrektur zur Zählung oben: Es sind +**zehn**, nicht neun — `concierge-bot` und `draupnir` kamen beim genauen Nachsehen dazu.) + +### Der Fallstrick, der die Umsetzung fast wirkungslos gemacht hätte + +NetworkPolicies sind additiv. Der Ausschluss steht deshalb **in +`egress-block-metadata` selbst**, nicht in einer zusätzlichen strengen Policy — solange +irgendeine Policy `0.0.0.0/0` für einen Pod erlaubt, ändert eine zweite, strengere +nichts. Genau das wäre die naheliegende Umsetzung gewesen. + +Zwei Dinge vorher **gemessen statt angenommen**: + +- **`NotIn` wählt auch Pods, die das Label gar nicht tragen.** Im Cluster geprüft: 29 + Pods, ein Treffer, `notin` liefert 28. Ohne diese Gewissheit hätten drei Pods ohne + `app.kubernetes.io/name` — darunter `coturn` — ihren Metadaten-Schutz verloren. +- **Die Selektoren gegen den laufenden Cluster gerechnet:** 20 behalten breiten Ausgang, + 9 laufende Pods werden eng, Summe 29 = Gesamtzahl. Kein Pod fällt durch, keiner ist + doppelt erfasst. + +Zwei Policies waren nötig, weil ein `podSelector` nicht über zwei Label-Schlüssel odern +kann und drei Pods im Namespace nur `app` führen. + +### Abnahme + +| Prüfung | Ergebnis | +|---|---| +| `wikijs-postgres` → rohana:443 und 10.0.0.3:9090 | **zu** — die Sperre beißt | +| `element-web-docs` → Internet und CFGMON | **zu** | +| `element-web-docs` → DNS | funktioniert | +| `synapse` → rohana, CFGMON, 1.1.1.1 | **offen** — breite Pods unberührt | +| Gruppenprüfung (Pod → Postgres, beide eng) | **erfolgreich** | + +⚠️ Zwei eigene Fehlmessungen auf dem Weg, beide erst durch Kontrollen aufgefallen: +`10.43.0.1:443` ist auch aus einem Pod **mit** breitem Ausgang nicht erreichbar (untaugliches +Testziel), und `/dev/tcp` ist eine bash-Eigenheit — im Synapse-Container mit dash meldet +es *immer* Fehlschlag. Ohne die Gegenprobe mit Python hätte hier „Synapse ist blockiert" +gestanden. + +### Praktische Nebenwirkung + +`element-web-docs` diente bisher als Sprungbrett, um von außen den operating-Stack auf +`10.0.0.3` abzufragen. Das geht nicht mehr — richtig so, aber für künftige Diagnosen ist +`matrix-stack-synapse-main-0` der passende Pod. + +### Was offen bleibt + +Die sechs Arbeitslasten mit genau einem Ziel (Storage Box, rohana) und die fünf mit +breitem Bedarf. Für Letztere gilt weiterhin: Bei Synapse ist die URL-Vorschau der Grund, +und sie hat mit `url_preview_ip_range_blacklist` bereits die richtige Kontrolle — die +Funktion abzuschalten wäre der falsche Hebel gewesen. + +⚠️ **In dieser Liste fehlt aber `169.254.0.0/16`** — das Netz des Cloud-Metadaten-Dienstes. +Heute deckt die NetworkPolicy das ab; sobald das Egress-Modell umgebaut wird, sollte es +auch in Synapses eigener Sperrliste stehen. Ebenfalls nicht enthalten: `100.64.0.0/10`.