#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.
This commit is contained in:
Thore Cimbal
2026-08-20 12:00:00 +00:00
parent 7cda0ee91a
commit 803488f53b
@@ -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.