From 803488f53b212eb6e25767934d329bcda9f241b7 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Thu, 20 Aug 2026 12:00:00 +0000 Subject: [PATCH] #0088: nein, etwa die Haelfte der Pods braucht kein Internet Arbeitslasten durchgegangen: neun von zwanzig brauchen gar keinen Ausgang, sechs genau ein Ziel (Storage Box, rohana), fuenf tatsaechlich breiten Zugang - Synapse wegen aktiver URL-Vorschau, clamav wegen freshclam, coturn und SFU wegen Medien. Wichtiger technischer Punkt: NetworkPolicies sind additiv. egress-block-metadata waehlt ALLE Pods und erlaubt 0.0.0.0/0 - eine zusaetzliche enge Policy fuer einen einzelnen Pod aendert daran nichts. Der Rueckbau muss das Modell drehen: default-deny-egress plus ausdrueckliche Erlaubnis je Arbeitslast, so wie es beim Ingress bereits ist. Zuordnungen sind aus Konfiguration und Aufgabe abgeleitet, nicht gemessen - das steht auch so im Issue. --- ...kpolicy-ausgehender-verkehr-ist-unbesch.md | 63 +++++++++++++++++++ 1 file changed, 63 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 db89a4b..37882e9 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 @@ -165,3 +165,66 @@ Vorschau) und die Backup-Jobs (Storage Box) eigene Betrachtungen brauchen. **Nicht mehr zutreffend** ist damit die Zuspitzung „ausgehender Verkehr ist unbeschränkt": Er ist eingeschränkt, aber nur gegen ein einziges Ziel. + +## Nachgefasst 2026-08-20 — nein, etwa die Hälfte braucht gar kein Internet + +Frage sorb: *„muss wirklich jeder Pod das Internet erreichen?"* Die Arbeitslasten im +Namespace `matrix` durchgegangen, mit Beleg wo vorhanden: + +### Braucht gar kein Internet — nur DNS und Cluster-intern + +`matrix-stack-element-web`, `element-web-docs`, `matrix-stack-element-admin` (nginx, +liefern statische Dateien aus) · `matrix-stack-postgres`, `wikijs-postgres` · +`clamav-http-scanner` (spricht ausschließlich clamd) · `wikijs-gruppenpruefung` (nur die +Wiki-DB) · `matrix-stack-haproxy` · `concierge-bot` und `draupnir` (sprechen Synapse +in-cluster; bei geschlossener Föderation gibt es für Draupnir ohnehin keine fremden +Policy-Listen). + +**Das sind neun von zwanzig Arbeitslasten.** + +### Braucht genau ein Ziel + +| Arbeitslast | Ziel | +|---|---| +| `synapse-backup`, `wikijs-backup`, `restore-drill` | Storage Box `:23` | +| `wikijs` | rohana `:443` (Git-Storage, ADR-0015) | +| `turn-secret-rotation` | rohana `:443` (schiebt den Rotationszweig) | + +### Braucht tatsächlich breiten Zugang + +- **`synapse-main`** — `url_preview_enabled: true` und `oembed_enabled: true`. Die + URL-Vorschau holt **beliebige** von Nutzern verlinkte Adressen; das ist per Entwurf + unbegrenzt. +- **`clamav`** — Signatur-Updates über freshclam. +- **`coturn`** und **`matrix-stack-matrix-rtc-sfu`** — relayen Medien zu beliebigen + Gegenstellen. +- **`matrix-rtc-authorisation-service`** — prüft OpenID-Token über den **öffentlichen** + Hostnamen des Homeservers. +- **`matrix-authentication-service`** — OIDC gegen Authentik, teils über öffentliche + Adressen. + +### ⚠️ Der Fallstrick, der die naheliegende Umsetzung wirkungslos macht + +NetworkPolicies sind **additiv**: Erlaubt *irgendeine* Policy den Verkehr, ist er +erlaubt. `egress-block-metadata` wählt **alle** Pods und erlaubt `0.0.0.0/0` (außer dem +Metadaten-Dienst). Eine zusätzliche, enge Policy für `element-web` würde daran **nichts** +ändern — der breite Erlaubnissatz gilt weiter. + +Ein Rückbau muss deshalb das Modell drehen, so wie es beim Ingress bereits ist: +**`default-deny-egress` für alle Pods, danach je Arbeitslast eine ausdrückliche +Erlaubnis.** `egress-block-metadata` in seiner heutigen Form entfällt dabei — die +Metadaten-Sperre ergibt sich dann von selbst, weil nichts mehr pauschal erlaubt ist. + +### Vorschlag für die Reihenfolge + +1. **Die neun ohne Bedarf zuerst.** Risiko gering, Wirkung sofort messbar; ein Fehler + zeigt sich als Ausfall genau eines Dienstes, nicht als stiller Datenabfluss. +2. **Die sechs mit einem Ziel** — Adressen sind bekannt und stabil. +3. **Die fünf mit breitem Bedarf** zuletzt und einzeln bewerten. Bei Synapse ist die + ehrliche Frage vorgelagert: Soll die URL-Vorschau überhaupt aktiv bleiben? Sie ist der + einzige Grund für unbegrenzten Ausgang und zugleich ein bekannter Weg, den Server zu + beliebigen Adressen greifen zu lassen. + +⚠️ 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.