Sicherheitsbefunde aus Trivy: Bestandsaufnahme über alle Charts und automatische Prüfung vor dem Ausrollen #7
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#7
Reference in new issue
Block a user
Auswertung der Trivy-Berichte aus dem laufenden Cluster durch die cluster-config-Session: 21 Deployments in 19 Namespaces. Dieses Issue sammelt die Befunde und trennt sie nach Zuständigkeit.
WICHTIG: Ein großer Teil der Härtungsbefunde ist bereits behoben — im Chart, nicht im Cluster
Trivy misst den ausgerollten Zustand, nicht den Chart-Stand auf
main. Stichprobe gegenmain:Beide Charts sind gehärtet — Trivy meldet sie trotzdem als „Default security context", „Root file system is not read-only" und „Runs as root user". Der Cluster fährt dort ältere Chart-Versionen als die veröffentlichten. Dasselbe gilt aller Wahrscheinlichkeit nach für die übrigen sieben Charts aus dieser Gruppe, die alle die Härtungsrunde aus #32 durchlaufen haben.
Die betroffenen Workloads (calibre-web, samba, homeassistant, matrix-synapse, outline, satisfactory, teamspeak-server, urlaubsverwaltung, voucher-vault) brauchen also keine neue Härtungsrunde im Chart, sondern ein Hochziehen im Cluster. Vor jeder Chart-Arbeit ist je Chart abzugleichen, welche Version deployt ist und welche auf main steht — sonst wird Vorhandenes ein zweites Mal gebaut.
Betrifft: AVD-KSV-0118, -0014, -0012, -0001, -0003, -0004 — also den Großteil der Meldungen.
Echte Chart-Lücken
1.
seccompProfile: RuntimeDefaultfehlt überall — auch imtemplate-chart.Verifiziert: Kein einziges Chart im Repo setzt es. Betrifft AVD-KSV-0104 (31x) und AVD-KSV-0030 (27x) und damit praktisch jeden Namespace, einschließlich der bereits gehärteten Charts. Das ist die Änderung mit der größten Hebelwirkung, weil sie einheitlich ist und keine chartspezifische Analyse braucht.
2. Das nginx-Image bei matrix-synapse ist unser Pin.
matrix-synapse/values.yamllegtrepository: nginxfest, aktuell1.28.3— mit 9 CRITICAL und 120 HIGH. Anders als bei Anwendungs-Images bestimmen wir diesen Tag selbst; es geht um einen reinen Delegations-Reverse-Proxy. Ein aktuelleres oder schlankeres Basis-Image (z. B. eine alpine-Variante) dürfte die Zahl deutlich senken. Zu prüfen, ob die gemountetenginx.confmit einer schlankeren Variante kompatibel bleibt.3. Kleinere, gezielte Punkte (je Chart zu bewerten, teils bewusste Abweichungen):
runAsUser: 0: paperless (3x)Ausdrücklich NICHT unsere Baustelle
homeassistant-WireGuard-Sidecar. Die vier schwersten Befunde des gesamten Bestands stammen aus einem von Hand ergänzten Sidecar, nicht aus unserem Chart:
Daraus folgen KSV-0017, -0120, -0013 und -0023. Unser eigener homeassistant-Container ist dagegen sauber (
drop: ALL, nurNET_RAWergänzt). Der Sidecar ist auch der Grund für die dauerhafteModified-Meldung des Bundles. Diese vier Befunde nicht im Chart jagen — sie sind dort nicht drin.AVD-KSV-0125 (vertrauenswürdige Registries, 25x). Trivy prüft gegen seine Standardliste;
cr.jk-dev.deundghcr.iostehen nicht darauf. Das ist eine Policy-Entscheidung (Liste konfigurieren oder Befund akzeptieren), kein Chart-Fehler.Image-Schwachstellen (Abschnitt C). 19 Images, in Summe 155 CRITICAL / 1619 HIGH. Nur über App-Versionen behebbar, also normale Update-Arbeit — mit Ausnahme des nginx-Falls oben. Die schwersten: paperless-ngx 3.0.5 (32 CRIT), gotenberg 8.36.0 (14), voucher-vault 1.30.1 (13), nginx 1.28.3 (9), rallly 4.12.3 (6), synapse v1.159.0 (5), outline 1.9.2 (5).
Exposed Secrets (4 Befunde). Alle in Upstream-Images: Test-Zertifikate einer Python-Bibliothek (calibre-web, 2x), ein mutmaßlicher Fehlalarm in minifiziertem JS (outline), ein JWT im pip-Cache eines Build-Artefakts (voucher-vault). Keine Maßnahme nötig.
RBAC: null Befunde.
Der eigentliche Wunsch: automatische Prüfung vor dem Ausrollen
Trivy läuft im Cluster bereits und erzeugt diese Berichte fortlaufend — was fehlt, ist die Prüfung vor der Veröffentlichung. Naheliegend wäre
trivy configgegen die gerenderten Manifeste als Schritt imvalidate-charts.yml-Workflow, zunächst berichtend, später als Gate.Zu klären:
ci/excluded-charts.txt.trivy imageauf die gepinnten Images laufen soll. Das würde die Abschnitt-C-Befunde früh sichtbar machen, hängt aber an fremden Release-Zyklen und darf deshalb nicht blockieren.Reihenfolge-Vorschlag
mainzurückliegen — das erledigt vermutlich den Großteil ohne eine Zeile Chart-Code.seccompProfile: RuntimeDefaultrepo-weit inklusivetemplate-chartund README-Style-Guideline.Bestandsaufnahme vor der Umsetzung: was inzwischen erledigt ist
Geprüft gegen den aktuellen Stand von
origin/main, nicht gegen die ursprüngliche Trivy-Auswertung. Seit deren Erhebung sind alle Charts durch das Schema-Programm (#68/#93/#99) gelaufen und tragen neue Versionen.Erledigt — und zwar größtenteils, bevor dieses Issue geschrieben wurde
Die Härtungsbefunde (AVD-KSV-0118, -0014, -0012, -0001, -0003, -0004) sind auf Chart-Ebene gegenstandslos. Die Trivy-Auswertung maß den ausgerollten Zustand; der Cluster fuhr dort ältere Chart-Versionen. Auf
mainsind die neun genannten Charts gehärtet.Übrig bleiben genau zwei Charts mit gelockertem Root-Dateisystem, beide dokumentierte Abweichungen mit Begründung:
calibre-web-automated:readOnlyRootFilesystem: false— im Read-only-Modus deaktiviert das Image seine Benutzer-Remappung, die Laufzeit-uid wechselt von 1000 auf 911, bestehende Volume-Daten werden unbrauchbar.samba:readOnlyRootFilesystem: false— der Entrypoint schreibt ins Root-Dateisystem.Dazu
homeassistantmit absichtlich leerem Pod-Context (das Image muss als root starten). Alle drei sind invalues.yamlbegründet und gehören nicht „behoben".Für die Cluster-Seite bleibt der eigentliche Punkt: Die Befunde verschwinden erst, wenn dort die neuen Chart-Versionen gezogen werden. Das ist keine Chart-Arbeit.
Offen — echte Chart-Lücken
1.
seccompProfile: RuntimeDefaultfehlt weiterhin überall. Verifiziert: null Treffer über allevalues.yaml, einschließlichtemplate-chart. Betrifft AVD-KSV-0104 (31×) und AVD-KSV-0030 (27×) und damit praktisch jeden Namespace — auch die bereits gehärteten Charts. Weiterhin die Änderung mit der größten Hebelwirkung, weil sie einheitlich ist.2. Trivy ist nicht in der CI. Verifiziert: kein Treffer in
.github/oderci/. Der eigentliche Wunsch — Prüfung vor dem Ausrollen statt fortlaufender Berichte aus dem Cluster — ist unerfüllt.3. Das nginx-Image bei matrix-synapse steht inzwischen auf
1.30.4, nicht mehr auf dem in der Auswertung gemeldeten1.28.3. Die dort genannten 9 CRITICAL / 120 HIGH bezogen sich auf den alten Stand. Zu prüfen bleibt, ob der aktuelle Tag noch nennenswerte Befunde trägt und ob eine schlankere Variante (alpine) mit der gemountetennginx.confverträglich wäre.Offen — aber Entscheidungen, keine Umsetzung
AVD-KSV-0020/-0021 (UID/GID ≤ 10000), ~30×. Die Charts fahren durchweg kleine uids: 33, 101, 1000, 1001, 1002, 9987, 35002, 65532. Sie anzuheben ist nicht risikofrei —
calibre-web-automatedist der Beleg, dass ein uid-Wechsel bestehende Volume-Daten unbrauchbar machen kann, und mehrere Charts pinnen ihre uid bewusst auf den Wert, den das Image erwartet (minecraft-serveruid 1000 = gosu-Default,teamspeak-server9987,voucher-vault33). Empfehlung: als bewusste Abweichung dokumentieren statt anheben.AVD-KSV-0011 (CPU nicht begrenzt), 13×. Das ist Repo-Konvention: bewusst keine CPU-Limits, Drosselung statt OOM-Kill. Als dokumentierte Abweichung führen.
AVD-KSV-0125 (vertrauenswürdige Registries), 25×. Policy-Entscheidung, kein Chart-Fehler.
Nicht unsere Baustelle, unverändert
Der homeassistant-WireGuard-Sidecar (vier schwerste Befunde, von Hand ergänzt, nicht im Chart) und die Image-Schwachstellen aus Abschnitt C (normale App-Update-Arbeit).
Vorgeschlagene Reihenfolge
seccompProfile: RuntimeDefaultüber alle Charts plustemplate-chartund README-Guideline.Entscheidungen des Users (2026-08-23)
1. UID/GID ≤ 10000 (AVD-KSV-0020/-0021, ~30×): dokumentieren, nicht ändern
Die Werte bleiben, wo sie sind, und werden als bewusste Abweichung in der Trivy-Ausnahmeliste geführt — mit Begründung, nicht als pauschales Abschalten.
Der Grund ist konkret, nicht prinzipiell: Mehrere Charts pinnen ihre uid auf genau den Wert, den das Image erwartet (
minecraft-server1000 = gosu-Default,teamspeak-server9987,voucher-vault33,matrix-synapse101 für den nginx). Undcalibre-web-automatedist der Beleg, wohin ein uid-Wechsel führen kann: Dort kippt die Laufzeit-uid von 1000 auf 911, sobald man das Root-Dateisystem read-only setzt — mit dem Ergebnis, dass bestehende Volume-Daten unbrauchbar werden. Eine Anhebung über 10000 hätte bei jedem Chart mit PVC dieselbe Klasse Risiko.2. Vertrauenswürdige Registries (AVD-KSV-0125, 25×): Liste konfigurieren
Trivy bekommt
cr.jk-dev.deundghcr.ioals vertrauenswürdig mitgegeben, statt den Check abzuschalten.Der Unterschied ist wesentlich: Ein abgeschalteter Check meldet auch dann nichts, wenn irgendwann ein Image aus einer wirklich fremden Quelle auftaucht. Eine konfigurierte Liste hält den Check aussagekräftig und beseitigt nur das Rauschen.
3. nginx-Image bei matrix-synapse: alpine-Variante prüfen
Das Image steht inzwischen auf
1.30.4, nicht mehr auf dem gemeldeten1.28.3. Zu prüfen ist der Wechsel auf1.30.4-alpine, weil der Delegations-Proxy nichts weiter tut, als zwei statische JSON-Antworten auszuliefern — die Angriffsfläche eines vollen Debian-Images ist dafür unnötig.Zu verifizieren, nicht anzunehmen: ob die gemountete
nginx.confmit der alpine-Variante unverändert funktioniert, ob der unprivilegierte Port 8080 und uid 101 dort dieselben sind, und ob die/tmp-Umleitung für pid-Datei und temporäre Pfade greift. Ein Vergleich der Trivy-Befunde beider Varianten gehört in den PR.Wird gemeinsam mit dem
seccompProfile-PR für dieses Chart umgesetzt — beide fassenmatrix-synapse/values.yamlan, und zwei getrennte Veröffentlichungen samt Hochzieh-Runden wären für die Cluster-Seite unnötiger Aufwand.Nachtrag zur Gate-Empfehlung: KSV-01010 gehört nicht in die erste Gruppe
Bei der Prüfung der template-chart-Befunde ist ein Punkt aufgefallen, der die Gate-Einteilung präzisiert.
KSV-01010 (sensible Daten in ConfigMaps) ist von Natur aus rauschanfällig. Der Check matcht die Namen der data-Keys gegen eine Musterliste, die unter anderem
key,username,email,phone,md5,sha1undibanenthält. Ein Chart mit einem völlig legitimenpublic_key_pathoderapi_key_namein seiner Konfiguration geht damit rot, ohne dass irgendetwas Sensibles darin steht.Heute trifft er nur die Vorlage, deren Platzhalter buchstäblich
keyheißt. Als Gate würde er aber irgendwann jemanden für einen korrekten Konfignamen bestrafen — und genau das ist der Mechanismus, durch den ein Gate seine Glaubwürdigkeit verliert.Empfehlung: berichtend lassen, im Einzelfall beurteilen. Nicht in die erste Gate-Gruppe.
Und ein echter Fehler in der Vorlage, kein Artefakt
template-chartsetzt gleichzeitigrunAsNonRoot: true,runAsUser: 20000undcapabilities.drop: [ALL]— und lässt den Container auf Port 80 lauschen. OhneNET_BIND_SERVICEkann ein Container als uid 20000 dort nicht binden; wer die Vorlage wörtlich nimmt, bekommtEACCESbeim Start.Kein einziges echtes Chart im Repo nutzt einen privilegierten Port außer samba (139/445), das die Capability genau dafür ergänzt. Die Vorlage ist der einzige Ausreißer — und sie lehrt eine Kombination, die mit ihren eigenen Härtungs-Defaults nicht funktioniert.
Wird zusammen mit dem Platzhalter-Key und dem unqualifizierten Image-Platzhalter korrigiert, statt als Ausnahme geführt zu werden. Eine Vorlage lehrt, was in ihr steht.
Randnotiz zur UID-Entscheidung
Die Vorlage steht bereits auf
runAsUser: 20000, also über der 10000-Grenze von KSV-0020/-0021. Neue Charts erben damit schon heute den Wert, den der Check sehen will — die beschlossene Ausnahme deckt nur den Bestand, nicht den Zuwachs, und wird mit der Zeit kleiner statt größer.Korrektur: Die EACCES-Begründung zum template-chart-Port war falsch
In meinem vorherigen Kommentar stand, ein Container als uid 20000 ohne
NET_BIND_SERVICEkönne Port 80 nicht binden und scheitere mitEACCES. Das stimmt nicht. Gemessen unter exakt dem securityContext der Vorlage:Der Grund: Der Kubelet setzt
net.ipv4.ip_unprivileged_port_start=0im Netzwerk-Namespace des Pods — aus dem laufenden Pod ausgelesen, Wert0. Die Regel "Ports unter 1024 brauchen NET_BIND_SERVICE" gilt innerhalb eines Pods nicht. Der Trivy-Befund KSV-0117 ist eine reine Policy-Regel gegencontainerPort < 1024, keine Aussage über Capabilities.Ich hatte die Begründung ungeprüft weitergegeben. Sie wurde beim Umsetzen gemessen und nicht übernommen — richtig so:
template-chartwird in jedes künftige Chart kopiert, und ein Kommentar, derEACCESbehauptet, wäre eine falsche Aussage mit genau der Reichweite, die die README-Sektion "Values that must not lie" bekämpft. Wer sie nachprüft, stellt fest, dass Port 80 funktioniert — und hält dann den ganzen Kommentar für falsch.Der Wechsel auf 8080 bleibt, mit der belegten Begründung: Der permissive sysctl ist ein Laufzeit-Default, keine Garantie. Ein Cluster, der
ip_unprivileged_port_start=1024wiederherstellt, bricht jedes Chart, das die 80 aus der Vorlage kopiert hat — und der Fehler erscheint dann im kopierten Chart, nicht in der Vorlage.Ein fünfter Fehler in der Vorlage, nur beim Ausrollen sichtbar
Die Vorlage rendert
env-Werte ohne| quote. Ein Wert wie"8080"wird damit zur YAML-Zahl, und die Kubernetes-API lehnt daraufhin das gesamte Manifest ab:Jedes echte Chart im Repo quotet dort — nur die Vorlage nicht, aus der sie alle kopiert wurden. Gefunden wurde das nur, weil die Vorlage nach dem README-Verfahren instanziiert und installiert wurde, statt sie bloß zu rendern. Ein reiner Rendering-Test hätte es nicht gezeigt.
Offen: KSV-0021 feuert weiterhin an der Vorlage
runAsUsersteht auf 20000, aberrunAsGroupundfsGroupstehen auf1000— die Gruppen-Grenze erbt also jedes neue Chart weiterhin als Befund. In der Vorlage wäre das Anheben risikofrei, weil dort keine Volume-Daten stranden können.Das ist bewusst nicht im Template-PR mitgemacht worden: Es ist eine Entscheidung, keine Reparatur, und gehört zur UID/GID-Diskussion oben. Meine frühere Aussage, die Ausnahme decke „nur den Bestand, nicht den Zuwachs", stimmt damit nur für uid, nicht für gid.
Nachtrag zum Port-Thema: NET_BIND_SERVICE hilft bei Nicht-Root-Prozessen nicht
Bei der Arbeit am rss-bridge-Chart (#128) wurde die Port-Frage ein drittes Mal gemessen, und das Ergebnis präzisiert die Guidance im
template-chart.Messung: Mit zurückgesetztem
ip_unprivileged_port_start=1024scheitert nginx beim Binden von Port 80 identisch mit und ohneNET_BIND_SERVICE:Der Grund: Bei einem Nicht-Root-Prozess landet die Capability im permitted-, nicht im effective-Set. Sie hinzuzufügen hätte also schützend ausgesehen und nichts bewirkt — Cargo-Kult mit Sicherheitsanstrich.
Das Chart pinnt deshalb
net.ipv4.ip_unprivileged_port_start: "0"selbst im Pod-Context, statt sich auf den Cluster-Default zu verlassen. Port 80 ist dort nicht verhandelbar: nginx ist im Image darauf konfiguriert, und der Entrypoint kann es nur über einsedgegen ein read-only/etc/nginxändern.Konsequenz für die Vorlage: Der Kommentar in
template-chart/values.yamlnennt derzeit samba als einziges Präzedenz für privilegierte Ports und verweist aufNET_BIND_SERVICE. Das ist für samba richtig — es läuft als root, dort landet die Capability im effective-Set. Für ein Chart mit Nicht-Root-Prozess ist es irreführend.Offener Punkt: Die Formulierung sollte um den Nicht-Root-Fall ergänzt werden — zwei Wege für zwei verschiedene Situationen, nicht einer für beide. Wird beim nächsten Anfassen des template-chart nachgezogen.
Und ein Befund zur Fehlerform, der über dieses Chart hinausgeht
Der rss-bridge-Entrypoint startet nginx im Hintergrund und exec't dann php-fpm. Ein fehlgeschlagener Bind hinterlässt damit einen Container, der
Runningmeldet und keinen Webserver hat — beide Testpods standen auf Running.Sichtbar wird das ausschließlich durch die Health-Probes. Das ist ein weiteres Argument für Guideline 5 ("Probe-Defaults brauchen ihren Kontext"): Ohne Probe ist ein solcher Pod von außen nicht von einem gesunden zu unterscheiden.
Freigegebener Umsetzungsplan für den Rest von #84 (2026-08-24)
Erhoben gegen
origin/mainauf Stand077030e, nicht gegen die ursprüngliche Trivy-Auswertung.Zwei Korrekturen am bisherigen Stand
Es fehlen 14 Charts, nicht fünf. Erledigt sind bisher nur
apache-tika,cyberchef,gotenberg,rallly,template-chartundrss-bridge. Offen:calibre-web-automated,homeassistant,matrix-synapse,minecraft-router,minecraft-server,outline,paperless-ngx,patchmon,samba,satisfactory,teamspeak-server,urlaubsverwaltung,voucher-vault,zipline.Die unqualifizierten Docker-Hub-Referenzen sind 14 in 12 Charts, nicht zehn:
apache/tika,gotenberg/gotenberg,nginx,busybox,itzg/mc-router,itzg/minecraft-server,alpine:3.22,outlinewiki/outline,lukevella/rallly,guacamole/guacd:1.6.0,teamspeaksystems/teamspeak6-server,urlaubsverwaltung/urlaubsverwaltung,l4rm4nd/vouchervault(zweimal). Nurrss-bridgeist bereits qualifiziert.Eine geprüfte Entwarnung zur Renovate-Kopplung
Die Präfixe brechen die
customManagersnicht: Sie lesenappVersion:ausChart.yamlund tragen den Repository-Namen fest inrenovate.json5, nicht aus dem Template.Ungeklärt bleibt das Verhalten der eingebauten Manager bei
alpine:3.22undguacamole/guacd:1.6.0, sobald dort eindocker.io/davorsteht. PR #138 belegt, dass beide tatsächlich verfolgt werden — ein stiller Verlust dieser Verfolgung wäre genau die Fehlerklasse, die dieses Repo gerade mehrfach getroffen hat (Regel greift, meldet sich aber nicht).Entscheidungen des Users
1. PR-Zuschnitt: Gruppen-PRs (8 + 5). Härtung und Registry-Präfix werden pro Chart im selben PR erledigt. Getrennt wären es 26 Veröffentlichungen und ebenso viele Hochzieh-Runden für die Cluster-Seite statt 13. Das Risiko des Sammel-PRs ist benannt: ein fehlschlagender Install-Test blockiert die übrigen sieben mit.
2.
homeassistantbekommt keinseccompProfile. Es wird als begründete Ausnahme geführt. Folge: Da sein Image mitghcr.iobereits qualifiziert ist, bleibt keine Chart-Änderung übrig — die Ausnahme gehört allein in die Trivy-Konfiguration. Ein Kommentar in dervalues.yamlerzwänge eine Veröffentlichung für reinen Text, was das Repo bei den Renovate-Kommentaren bereits bewusst vermieden hat.Umsetzung
Stufe 1 — Sammel-PR, acht Charts.
minecraft-router,outline,urlaubsverwaltung,zipline,voucher-vault,satisfactory,patchmon,calibre-web-automated. Je ChartseccompProfile: RuntimeDefaultim Pod-Context,docker.io/-Präfix wo nötig, eigene Versionsnummer.Stufe 2 — fünf Sonderfälle, je ein eigener PR.
matrix-synapse— zwei Container, dazu die in diesem Issue beauftragte alpine-Prüfung: bleibt die gemountetenginx.confunverändert funktionsfähig, sind Port 8080 und uid 101 dort dieselben, greift die/tmp-Umleitung? Ein Trivy-Vergleich beider Varianten gehört in den PR.paperless-ngx— mehrere Workloads inklusive CronJob; alle brauchen den Eintrag, nicht nur der Server.minecraft-server— Init-Container, plusdocker.io/-Präfix füralpine.sambaundteamspeak-server— gelockertes bzw. eigenwilliges Root-Dateisystem; das Startverhalten unter dem Profil ist im k3d zu belegen, nicht anzunehmen.Stufe 3 —
homeassistantals begründete Ausnahme ausschließlich in der Trivy-Konfiguration, ohne Chart-Änderung und ohne Veröffentlichung.Stufe 4 — Gate-Entscheidung, sobald der Befundstand stabil ist: drei Gruppen (heute gate-fähig / nach Aufräumen / dauerhafte Ausnahmen),
KSV-01010ausdrücklich nicht in der ersten Gruppe. Offen bleibt dabei, dassKSV-0021weiterhin auftemplate-chartfeuert, weilrunAsGroup/fsGroupauf 1000 stehen — die dokumentierte Ausnahme deckt die uid ab, die gid aber nicht.Verbindliche Auflage an jeden PR
Vor dem Merge ist per Renovate-Lookup zu belegen, dass die präfigierten Images weiterhin auflösen. Ein Lookup gegen die heutige, unpräfigierte Form beweist das nicht — er bestätigt nur den Fall, der ohnehin funktioniert.
seccompProfilegehört in den Pod-Context. Das wurde am Init-Container-Fall entschieden und mit einem ephemeren Container belegt, derSeccomp: 2bei gleichzeitigNoNewPrivs: 0meldete.