#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.

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`.