#0083 und #0088 nachgemessen und fortgeschrieben

#0083: Die drei im Issue genannten Dateien (prometheus.yml, alerts.yml, alertmanager.yml) sind laengst Verzeichnis-Mounts - der vorgeschlagene Umbau ist dort umgesetzt. Offen sind noch fuenf Mounts: loki-config.yaml, config.alloy und drei .py-Skripte. Bei den Skripten ist die Falle schlimmer, nicht harmloser: Python liest beim Start, ein Neustart ist ohnehin noetig - und wird deshalb fuer ausreichend gehalten. Der Prozess startet neu, der Mount zeigt weiter auf den alten Inode, der Container meldet Erfolg und fuehrt alten Code aus. Ob die laufende cve-exporter-Instanz die Aenderung vom 19.08. ausfuehrt, ist ungeprueft. #0088: Beide Zahlen im Issue sind ueberholt - es sind 15 Ingress-Policies mit 21 Regeln, und eine Egress-Policy existiert inzwischen in drei Namespaces. Sie sperrt aber genau ein Ziel: den Metadaten-Dienst. Alles andere darf weiterhin ins Internet. Der Kern des Befunds gilt damit weiter, nur die Zuspitzung 'unbeschraenkt' nicht mehr. Beide Issues sagten Dinge, die so nicht mehr stimmen - genau die Klasse, die heute schon mehrfach Zeit gekostet hat.
2026-08-20 12:00:00 +00:00
parent f266ce912e
commit 7cda0ee91a
2 changed files with 86 additions and 0 deletions
@@ -59,3 +59,48 @@ Statt Einzeldateien die Verzeichnisse mounten (`./prometheus:/etc/prometheus:ro`
 ---
 *Migriert aus Gitea `sorb/axion1337.chat-gitops#52` — dort erstellt am 2026-08-01 von sorb.*
 <!-- gitea-migration: sorb/axion1337.chat-gitops#52 -->
+
+## Nachgemessen 2026-08-20 — zur Hälfte erledigt, der Rest ist enger als gedacht
+
+Das Issue nennt `prometheus.yml`, `alerts.yml` und `alertmanager.yml` als Einzeldatei-
+Mounts. **Für diese drei stimmt das nicht mehr.** Der vorgeschlagene Umbau auf
+Verzeichnis-Mounts ist dort umgesetzt; der Kommentar in `docker-compose.yml` nennt
+ausdrücklich diesen Fallstrick als Grund.
+
+Alle Bind-Mounts des Monitoring-Stacks, gemessen:
+
+| Dienst | Mount | Art |
+|---|---|---|
+| prometheus | `./prometheus:/etc/prometheus` | **Verzeichnis** ✅ |
+| alertmanager | `./alertmanager:/etc/alertmanager` | **Verzeichnis** ✅ |
+| cve-scan | `./cve:/config` | **Verzeichnis** ✅ |
+| grafana | `./grafana/provisioning`, `./grafana/dashboards` | **Verzeichnis** ✅ |
+| loki | `./loki/loki-config.yaml` | Einzeldatei ⚠️ |
+| alloy | `./alloy/config.alloy` | Einzeldatei ⚠️ |
+| matrix-alerts | `./alertmanager/matrix-alerts.py` | Einzeldatei ⚠️ |
+| release-watch | `./alertmanager/release-watch.py` | Einzeldatei ⚠️ |
+| cve-exporter | `./cve/cve-exporter.py` | Einzeldatei ⚠️ |
+
+### Bei den drei Skripten ist die Falle schlimmer, nicht harmloser
+
+Für eine Konfigurationsdatei merkt man den Fehlschlag im Zweifel daran, dass sich das
+Verhalten nicht ändert. Bei den `.py`-Dateien liegt der Fall unangenehmer: Python liest
+das Skript beim Start, ein Neustart ist also **ohnehin nötig** — und genau deshalb hält
+man ihn für ausreichend. `docker compose restart` startet den Prozess neu, der Mount
+zeigt aber weiterhin auf den alten Inode. Der Container läuft, meldet Erfolg und führt
+den alten Code aus.
+
+`cve-exporter.py` wurde am 2026-08-19 geändert (Prune-Verhalten, zwei neue Metriken).
+Ob die laufende Instanz diese Fassung ausführt, ist **ungeprüft** — `trivy_reports_total`
+existiert inzwischen, was dafür spricht, aber belegt ist es nicht.
+
+### Was noch zu tun bleibt
+
+Zwei Konfigurationsdateien (`loki-config.yaml`, `config.alloy`) und drei Skripte auf
+Verzeichnis-Mounts umstellen. Bei den Konfigurationen ändert sich dabei der Pfad im
+Container, also auch der jeweilige `-config.file`-Parameter — kein reiner
+Compose-Handgriff, aber ein kleiner.
+
+Der Titel des Issues ist damit überholt: Es geht nicht mehr um „Configs greifen nicht
+ohne `--force-recreate`", sondern um die verbliebenen fünf Mounts. Für Prometheus und
+Alertmanager genügt heute ein Neustart.
@@ -124,3 +124,44 @@ gleich**: `monitoring` und `authentik` haben eine überschaubare, benennbare Zie
 (CFGMON privat, IONOS-SMTP, ACME) — dort ist Default-Deny realistisch. `matrix` ist es
 wegen der Föderation nicht. Das Issue bleibt offen und trägt jetzt die Bestandsaufnahme,
 die diese Entscheidung tragfähig macht.
+
+## Nachgemessen 2026-08-20 — die Metadaten-Sperre steht, der Rest ist offen
+
+Das Issue nennt „13 Ingress-Regeln und genau ein Egress-Vorkommen". Beide Zahlen sind
+überholt. Gemessen am laufenden Cluster:
+
+| | Namespace `matrix` |
+|---|---|
+| Policies mit Ingress | **15** |
+| einzelne Ingress-Regeln | **21** |
+| Policies mit Egress | **1** (`egress-block-metadata`, greift auf **alle** Pods) |
+
+Dieselbe Egress-Policy existiert auch in `authentik` und `monitoring`.
+
+### Was sie tatsächlich tut
+
+```
+Regel 1: DNS nach kube-system            (UDP/TCP 53)
+Regel 2: 10.42.0.0/16 und 10.43.0.0/16   (Pod- und Service-Netz)
+Regel 3: 0.0.0.0/0 AUSSER 169.254.0.0/16 (alles, nur nicht der Metadaten-Dienst)
+```
+
+**Damit ist genau ein Ziel gesperrt: der Cloud-Metadaten-Dienst.** Alles andere darf
+weiterhin ins Internet. Das war eine bewusste Entscheidung — der Lehrbuch-Schnitt
+(`0.0.0.0/0 except RFC1918`) hätte Alloy und den Loki-Push über `10.0.0.3` zerrissen,
+beides läuft über das private Hetzner-Netz.
+
+### Was der ursprüngliche Befund meinte und was davon bleibt
+
+Der Kern des Issues — „eingehend ist alles geregelt, ausgehend darf jeder Pod überallhin"
+— **gilt weiterhin**. Ein kompromittierter Pod kann nach wie vor beliebige Ziele im
+Internet erreichen; er kommt nur nicht mehr an die Instanz-Metadaten und damit nicht an
+Cloud-Zugangsdaten.
+
+Ein vollständiger Egress-Schnitt bräuchte je Pod eine Liste erlaubter Ziele. Realistisch
+wären zuerst die Pods mit klar begrenztem Bedarf (Postgres-Instanzen, `clamav`,
+`coturn`), während Synapse (Föderation ist zwar geschlossen, aber Push-Gateways, URL-
+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.