Files

T

Thore CimbalandClaude Opus 4.8 9aea4ad69d docs(issues): close #0052 — no :latest left, coturn pinned and verified

The cluster was running coturn 4.10.0 while :latest pointed at 4.17.2, which is
the concrete harm the issue describes: nobody knew what ran, a reschedule would
have jumped seven minor versions unannounced, and the CVE scan was measuring a
moving target. Now pinned to 4.17.2 and verified beyond 'the pod is up' — a STUN
binding request from the public internet succeeds and the server reports the
caller's external address, so the relay path itself is proven.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-08-15 12:00:00 +00:00

3.1 KiB

Raw Blame History

type, id, status, created, milestone, priority, area, related

type

status

created

milestone

priority

area

issue

0052

done

2026-08-14

medium

infrastructure

docs/issues/0051-cve-remediation-pass.md

Update-Kadenz festlegen & `:latest`-Tags beseitigen

Problem / Motivation

Regelmäßige Komponenten-Updates sind der wirksamste CVE-Schutz (#0051), passieren bisher aber nur ad-hoc. Zudem ist coturn:latest unpinned — nicht reproduzierbar und nicht sauber scanbar — und busybox:1.28 ist veraltet.

Acceptance

coturn auf eine gepinnte, aktuelle Version; busybox aktualisiert; kein :latest-Tag mehr im gitops-Repo.
Update-Kadenz festgelegt (Richtwert monatlich + ad-hoc bei CRITICAL-CVE), dokumentiert auf /betrieb/upgrades.
Fork-Updates (ThreadNet-Web, threadnet-call) folgen der Portier-Checkliste (axion1337-fork.md).

Notes

Update-Prozess: /betrieb/upgrades. Bei DB-Migrationen (Authentik, Wiki.js) vorher Backup (die Backup-Jobs stehen). Rollback ist trivial (GitOps: Commit zurück).

Erledigt 2026-08-15

:latest ist aus dem Repo verschwunden (gitops b4650dc) — grep -rE '^\s*image:.*:latest' apps/ findet nichts mehr.

Der Befund, der die Dringlichkeit belegt

Im Cluster lief coturn 4.10.0, während :latest auf der Registry längst 4.17.2 zeigte. Mit imagePullPolicy: IfNotPresent hält der Node das einmal gezogene Image fest — niemand konnte wissen, was tatsächlich lief, und ein Reschedule auf einen frischen Node wäre still über sieben Minor-Versionen gesprungen. Nebenwirkung: der Trivy-Report maß gegen ein bewegliches Ziel, seine „12 CRITICAL für coturn:latest" beschrieben nicht zwingend das laufende Image.

Umgesetzt

Änderung	von	auf
coturn	`coturn/coturn:latest` (real 4.10.0)	`4.17.2`
busybox (init-Container)	`1.28` (2018)	`1.36` — die im Repo bereits anderswo genutzte Version

Vorher geprüft: Der Tag existiert (Registry-Abfrage — 4.10.0 gibt es dort gar nicht mehr, ein Pin darauf wäre fehlgeschlagen), und die Konfiguration nutzt ausschließlich langlebige Kern-Optionen (realm, use-auth-secret, relay-ip, cert/pkey), von denen keine im Versionsbereich entfallen ist.

Verifiziert

Pod läuft, Listener auf 3478 und 5349 (TLS/TCP), keine Fehler im Log.
turnserver --version im Container: 4.17.2.
Funktionstest von außen: STUN-Binding-Request an 49.13.132.245:3478 → Binding Success, und der Server meldet die externe Adresse des Anfragenden korrekt zurück. Der Relay-Pfad für Anrufe funktioniert also nachweislich, nicht nur der Prozess.

⚠️ Der Wechsel bedeutete einen coturn-Neustart; laufende Relay-Verbindungen wurden dabei getrennt. Bei künftigen TURN-Upgrades einplanen.

Kadenz

Der zweite Teil des Issues (Update-Kadenz) steht bereits im Betriebs-Wiki unter /betrieb/upgrades, Abschnitt „Kadenz & CVE-Bezug": monatlich als Richtwert, ad-hoc bei CRITICAL-CVE, Fork-Updates über die Portier-Checkliste. Erwartete Nebenwirkung für #0051: Der nächste Trivy-Lauf sollte für coturn deutlich weniger CRITICALs zeigen — und erstmals gegen ein festes Ziel messen.

3.1 KiB Raw Blame History

Update-Kadenz festlegen & :latest-Tags beseitigen