---
type: adr
id: "0021"
status: accepted
date: 2026-08-19
supersedes: null
superseded_by: null
related:
  - "docs/issues/0060-gitops-17-federation-allowlist-or-closed-federation-dec.md"
  - "docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md"
---

# ADR-0021: Föderation wird geschlossen — leere Whitelist statt offener Tür

## Kontext

Die Frage stand seit dem 2026-07-28 offen, weil niemand wusste, was eine Schließung
kosten würde. Am 2026-08-19 wurde sie gemessen statt geschätzt.

**Föderation war offen und öffentlich erreichbar.** In `synapse-values.yaml` stand zu
Föderation nichts, es galten die Synapse-Vorgaben; `/_matrix/federation/v1/version` und
`/_matrix/key/v2/server` antworteten von außen mit HTTP 200. Dass Port 8448 zu ist,
änderte daran nichts: Die Delegation in `/.well-known/matrix/server` führt die
Föderation über `matrix.axion1337.chat:443`, denselben Port wie den Client-Verkehr.

**Benutzt wurde sie nie.** Über die gesamte Betriebszeit seit dem 2026-04-21, aus der
Synapse-Datenbank: **0** Einträge in `destinations`, **0** je erfolgreich kontaktierte
Server, **0** fremde Nutzer in den 31 eigenen Räumen, **0** Räume mit fremder
Beteiligung. Nicht „wenig", sondern null.

Damit ist der Handel nicht „Reichweite gegen Sicherheit", sondern **eine ungenutzte
Fähigkeit gegen die größte fremdzugewandte Angriffsfläche, die Synapse hat** — und
historisch die, in der seine CVEs sitzen.

## Optionen

**A: offen lassen.** Kein Aufwand; dauerhaft Angriffsfläche für null nachgewiesenen
Bedarf.

**B: `federation_domain_whitelist: []`.** Föderation nur mit ausdrücklich genannten
Servern, leer also mit keinem. Eine Zeile, versioniert, in Minuten umkehrbar.
Die Endpunkte antworten weiterhin — der Server wird unbeteiligt, nicht unsichtbar.

**C: Föderations-Endpunkte am Rand sperren.** Zunächst als „kleinste Fläche" gewählt,
dann **verworfen** — beim Umsetzen zeigte sich, dass es die Gruppen-Calls zerstört
hätte (siehe unten).

## Entscheidung

**Option B.** `federation_domain_whitelist: []` in
`gitops:apps/production/custom-configs/synapse-values.yaml`.

## Warum C verworfen wurde — der Teil, der nicht offensichtlich ist

Der MatrixRTC-Authorisation-Service (`lk-jwt-service`) prüft OpenID-Tokens über
**`/_matrix/federation/v1/openid/userinfo`** — einen Föderations-Pfad. Und er ruft ihn
über den **öffentlichen** Namen auf: Das Deployment trägt keine `hostAliases` und
`dnsPolicy: ClusterFirst`, `matrix.axion1337.chat` löst also auf die öffentliche IP auf
und der Verkehr läuft über Traefik.

Wer `/_matrix/federation/` am Ingress sperrt, kappt damit die Token-Prüfung für
Gruppen-Calls — **derselbe Ausfall wie beim gelöschten `mrtc`-Record, nur mit anderer
Ursache.** Ein Pfad-Block sieht dabei korrekter aus als die Whitelist, weshalb dieser
Zusammenhang im Konfigurations-Kommentar festgehalten ist und nicht nur hier.

Synapse bedient diesen Endpunkt ohne X-Matrix-Signatur (`REQUIRE_AUTH = False`); die
Whitelist greift dort also nicht und darf es auch nicht.

## Konsequenzen

- Fremde Server können weder beitreten noch Ereignisse einliefern. Bestehende Räume und
  Nutzer sind nicht betroffen — es gab keine fremde Beteiligung, die enden könnte.
- **Die Fähigkeit ist eine Zeile entfernt**, nicht verloren: Ein Domain-Eintrag öffnet
  gezielt für einen Partner. Das war der Grund, B gegenüber einem harten Rückbau
  vorzuziehen.
- Die Endpunkte antworten weiterhin von außen. Wer das ändern will, muss **zuerst** den
  Auth-Service clusterintern an Synapse binden — sonst siehe oben. Das ist ein eigenes
  Vorhaben mit Call-Abnahme, kein Nebenschritt.
- Eine Port-Sperre bei Hetzner kann diese Trennung **nicht** leisten: Föderation und
  Client-Verkehr teilen sich 443. Die Konfiguration ist die einzige Stelle, an der sie
  überhaupt trennbar sind.