#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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user