diff --git a/docs/issues/0083-gitops-50-monitoring-deploy-geaenderte-configs-greifen.md b/docs/issues/0083-gitops-50-monitoring-deploy-geaenderte-configs-greifen.md index 168e495..55af29f 100644 --- a/docs/issues/0083-gitops-50-monitoring-deploy-geaenderte-configs-greifen.md +++ b/docs/issues/0083-gitops-50-monitoring-deploy-geaenderte-configs-greifen.md @@ -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.* + +## 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. 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 25ba7ab..db89a4b 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 @@ -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.