Thore CimbalandClaude Opus 4.8
51c05edb2d
Went through the seven imported waiting issues and replaced the generic 'reason is in the GitLab history' placeholder with the real blocker, which completes #0041. Three of the seven were not merely imprecise but wrong: - #0025: the deploy had long landed; screenshots confirm 24 aggregated messages in the security room (limit 29), summing to the known 126 CRITICALs. - #0014: the A/B/C decision exists as ADR-0008 (option A). Half its open question is now answered — MATRIX has no docker group at all, so the root-equivalence does not apply there. - #0027: the blocking Struktur-Workshop happened on 2026-08-06 and produced three ADRs, but W1 and W3 were spot-checked and are still unresolved. The remaining four wait on a named action by sorb. Measured from here: the GAME exporters are still filtered (and their silences expired on 2026-08-04, so TargetDown has been firing every 4h since), while CFGMON's 9090/3100 are already closed from the internet — so #0008 is about making that state deliberate rather than an acute exposure. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
84 lines
5.7 KiB
Markdown
84 lines
5.7 KiB
Markdown
---
|
||
type: issue
|
||
id: "0025"
|
||
status: done
|
||
created: 2026-08-01
|
||
milestone: M1
|
||
priority: medium
|
||
area: infrastructure
|
||
gitlab_iid: "25"
|
||
related: [docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md]
|
||
---
|
||
# Deploy-Übergabe: CVE-Alarme aggregiert + Receiver-Robustheit (gitops#51, ff87cb2)
|
||
|
||
> Import aus [management#25](https://git.lab/axion1337.chat/management/-/issues/25) (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).
|
||
|
||
### Stand
|
||
threadnet-operating `ff87cb2` (git.lab; Gitea-Mirror folgt — auf CFGMON vorher `git fetch && git reset --hard origin/main`, der gerettete Kollegen-Commit heißt jetzt `0bd77e2`)
|
||
|
||
### Testtiefe
|
||
ungetestet — Lints grün (promtool 9 Regeln, amtool, py_compile), kein Laufzeittest
|
||
|
||
### Mengengerüst
|
||
Erwartete Matrix-Nachrichten beim Scharfschalten: **eine pro Image mit CRITICAL-Funden**, obere Schranke 29 (gemessen an 14 Images hatten die meisten CRITICALs → realistisch ~15–25 Nachrichten, je 1 s gedrosselt ≈ unter 30 s). HIGH-Alarme folgen frühestens nach 24 h (`for: 24h`), gleiche Schranke. Danach nur Deltas (neue Images/Severity-Wechsel) und ✅-Edits. Kein Pro-CVE-Verkehr mehr: Regeln sind `count by (target, target_type, host)`, die ~1200 Einzelserien erzeugen keine Alarme mehr (bleiben aber als `trivy_vuln_info` fürs Dashboard).
|
||
|
||
### Vollständiges Deploy-Kommando
|
||
```
|
||
cd /opt/threadnet-operating && git fetch && git reset --hard origin/main && cd monitoring && docker compose up -d --force-recreate matrix-alerts && docker compose exec prometheus kill -HUP 1 && docker compose exec alertmanager kill -HUP 1
|
||
```
|
||
(reset --hard wegen Hash-Wechsel 2b715ca→0bd77e2; force-recreate lädt das ro-gemountete Receiver-Skript neu; HUPs laden Regeln/Route ohne Neustart)
|
||
|
||
### Woran erkennt man, dass es wirklich greift
|
||
1. `docker compose logs matrix-alerts --since 5m` — keine Fehler, keine 502-Schleife
|
||
2. Security-Raum: binnen ~2 min (group_wait 1m) trudeln die aggregierten 🔴-Nachrichten „Image X: N CRITICAL-CVEs" einzeln im Sekundentakt ein — **gezählt ≤ 29**, keine Pro-CVE-Flut
|
||
3. `curl -s localhost:9090/api/v1/rules | grep -c TrivyCriticalVulns` → 1 (neue Regel geladen)
|
||
4. Alertmanager-Retry-Probe: Log darf nach Abschluss der Zustellung keine wiederholten identischen Batches zeigen
|
||
|
||
### Außenwirkung und Not-Aus
|
||
Außenwirkung: nur der Security-Matrix-Raum (interner Kreis). **Not-Aus:** in `monitoring/alertmanager/alertmanager.yml` die Route `room="security"` wieder auf einen `"null"`-Receiver biegen (Muster steht in der Git-Historie, Commit `0bd77e2`) + `docker compose exec alertmanager kill -HUP 1` — wirkt sofort, Pipeline läuft weiter.
|
||
|
||
### Rollback
|
||
`git revert ff87cb2` (ein Commit, betrifft nur alerts.yml/alertmanager.yml/matrix-alerts.py) + dieselben drei Kommandos wie beim Deploy. State-Datei ist abwärtskompatibel (neues Format kapselt das alte unter `alerts`).
|
||
|
||
### Bewusst offen gelassen
|
||
- Grafana-Dashboard als **Matrix-Widget** im Security-Raum (Wunsch sorb): braucht `allow_embedding` in Grafana + Lese-Zugang ohne Login — eigener Punkt, nicht Teil dieses Deploys
|
||
- gitops#52 (Inode-Falle) unberührt
|
||
- Erste HIGH-Welle kommt erst nach 24 h — bewusst, keine Fehlfunktion
|
||
|
||
---
|
||
*Migriert aus Gitea `sorb/management#1` (Gitea-Tracker stillgelegt, ADR-0002) — dort erstellt am 2026-08-01 von sorb.*
|
||
<!-- gitea-migration: sorb/management#1 -->
|
||
|
||
## Erledigt 2026-08-15 — Deploy ist gelandet und nachweislich in Betrieb
|
||
|
||
Beim Ausbau der Backup-Alarme (#0030) fiel auf, dass dieses Übergabe-Issue noch `waiting`
|
||
stand, obwohl der Deploy längst live ist. Nachgeprüft:
|
||
|
||
| Abnahmekriterium | Nachweis |
|
||
|---|---|
|
||
| Deploy gelandet | `ff87cb2` ist **Vorfahr von HEAD**; CFGMON läuft inzwischen auf `e9c13dc` (zwei Commits darüber hinaus) |
|
||
| Kein Pro-CVE-Verkehr mehr | Regeln lauten `count by (target, target_type, host) (trivy_vuln_info{…})` — eine Alarm-Instanz je Image; die Flut ist **strukturell** ausgeschlossen, nicht bloß gedrosselt |
|
||
| Receiver-Robustheit | `matrix-alerts.py`: `save_state()` steht **inkrementell in der Sende-Schleife** („Teilfortschritt übersteht Fehler/Retry"), plus 1s-Drosselung gegen `rc_message` und Speichern im Fehlerpfad — genau der beschriebene Bug ist behoben |
|
||
| Regel geladen | 14 Regeln evaluieren mit `health=ok` (Stand 2026-08-15) |
|
||
| Keine 502-Retry-Schleife | `alertmanager_notifications_failed_total` = **0** über 80 Serien aller Integrationen |
|
||
| Not-Aus nicht mehr nötig | Die `room="security"`-Route auf den Null-Receiver existiert nicht mehr; `alertmanager.yml` hat nur die Default-Route auf den `matrix`-Receiver |
|
||
|
||
**Kriterium 2 nachträglich belegt (Screenshots sorb, 2026-08-15):** Im Security-Raum liegen
|
||
die aggregierten 🔴-Meldungen — **eine pro Image**, Format „Image X: N CRITICAL-CVEs" mit
|
||
Dashboard-Link, alle im selben Sendefenster (1:42). **24 Nachrichten**, also unter der
|
||
Obergrenze von 29; keine Pro-CVE-Flut, keine Wiederholungen. Die Summe der gemeldeten
|
||
CRITICALs ergibt 126 und deckt sich exakt mit dem bekannten Report-Stand — die
|
||
`trivy_vuln_info`-Serien kommen also vollständig an.
|
||
|
||
Das Issue wird trotzdem geschlossen: sein Zweck war die Übergabe eines Deploys, und der ist
|
||
gelandet, robust und ohne die befürchteten Nebenwirkungen. Die Zustellung ist seit
|
||
`e9c13dc` zudem **dauerhaft überwacht** (`AlertDeliveryFailing` auf
|
||
`alertmanager_notifications_failed_total`) — ein künftiger Zustellfehler meldet sich von
|
||
selbst, statt auf eine manuelle Sichtprüfung zu warten.
|
||
|
||
**Folgepunkt erledigt:** `TrivyCriticalVulns` feuert nachweislich (s.o.) — der Verdacht,
|
||
die `trivy_vuln_info`-Serien kämen nicht mehr an, ist ausgeräumt.
|
||
|
||
**Weiterhin bewusst offen (aus dem Original):** Grafana-Dashboard als Matrix-Widget im
|
||
Security-Raum — eigener Punkt, war nie Teil dieses Deploys.
|