sorb/management
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Deploy-Übergabe: CVE-Alarme aggregiert + Receiver-Robustheit (gitops#51, ff87cb2) #1

New Issue
Closed
opened 2026-08-01 14:12:21 +00:00 by sorb · 1 comment
sorb commented 2026-08-01 14:12:21 +00:00
Owner
Copy Link
Copy Source

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
### 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
sorb commented 2026-08-02 13:40:27 +00:00
Author
Owner
Copy Link
Copy Source

Umgezogen nach git.lab — LABNET-03 (2026-08-02).

Dieses Issue lebt jetzt als axion1337.chat/management#25. Beschreibung und alle Kommentare sind mit Originalautor und -zeitstempel übernommen.

Der Grund für die Ausnahme ist entfallen: Deploy-Übergaben liefen hier, weil CFGMON git.lab nicht erreichte. Seit dem Site-to-Site-Tunnel (LABNET-02, ADR-0004) genügt es, den Tunnel einzuschalten. Damit gilt wieder ohne Ausnahme: Issues leben auf git.lab (ADR-0002).

Bitte hier nicht weiterarbeiten.

**Umgezogen nach git.lab — LABNET-03 (2026-08-02).** Dieses Issue lebt jetzt als [axion1337.chat/management#25](https://git.lab/axion1337.chat/management/-/issues/25). Beschreibung und alle Kommentare sind mit Originalautor und -zeitstempel übernommen. Der Grund für die Ausnahme ist entfallen: Deploy-Übergaben liefen hier, weil CFGMON git.lab nicht erreichte. Seit dem Site-to-Site-Tunnel (LABNET-02, ADR-0004) genügt es, den Tunnel einzuschalten. Damit gilt wieder ohne Ausnahme: **Issues leben auf git.lab** (ADR-0002). Bitte hier nicht weiterarbeiten.
sorb closed this issue 2026-08-02 13:40:27 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/management#1