management/docs/issues/0044-sops-secret-aenderung-startet-dienst-nicht-neu.md

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

type	id	status	created	milestone	priority	area	related
issue	0044	done	2026-08-11	M5	low	infrastructure	docs/adr/0011-enrollment-localpart-kollision-verweigern.md

SOPS-Values-Secret-Änderung startet den konsumierenden Dienst nicht neu

Problem / Motivation

Beim Ausrollen des on_conflict: fail-Fixes (ADR-0011) trat ein Footgun zutage: Flux aktualisierte das SOPS-verwaltete Secret ess-mas-values-secret, aber der laufende MAS-Pod war älter als die Änderung und behielt die alte Config im Speicher — MAS liest seine Config nur beim Start. Der Sicherheits-Fix stand auf der Platte, war im Prozess aber nicht aktiv, bis ein manueller kubectl rollout restart folgte. „committet ≠ deployed ≠ aktiv."

Das betrifft nicht nur MAS: jeder Dienst, der ein von Flux/SOPS gepflegtes Values-Secret nur beim Start liest, hat dieselbe stille Lücke. Aktuell ist die einzige Absicherung die in ADR-0011 festgeschriebene manuelle Restart-und- Verifikations-Regel — leicht zu vergessen.

Acceptance

• Änderungen an einem konsumierten Values-Secret lösen automatisch einen Rollout des abhängigen Deployments aus (z. B. Checksum-/Hash-Annotation auf dem Pod-Template, ein Reloader wie stakater/Reloader, oder ein configMapGenerator/secretGenerator-Namenshash in kustomize).
• Verifiziert an MAS: Änderung am Secret → neuer Pod ohne Handeingriff, jünger als die Änderung.
• Mindestens MAS abgedeckt; idealerweise als wiederverwendbares Muster für weitere von SOPS-Secrets gespeiste Dienste.

Notes

Automatisiert nur den bereits in ADR-0011 vorgeschriebenen manuellen Schritt — daher priority: low. M5, weil die Fähigkeit (Auto-Reload) neu ist, nicht kaputt.

Untersuchung 2026-08-15 — die Abdeckung ist deutlich besser als angenommen

Vor dem Einbau eines Reloaders geprüft, wo die Lücke tatsächlich klafft. Ergebnis: der im Issue beschriebene Fall (MAS) ist bereits abgedeckt, und zwar von der Chart selbst.

MAS ist abgedeckt — verifiziert am laufenden Deployment. Die ESS-Chart hängt Prüfsummen als Labels ans Pod-Template (templates/matrix-authentication-service/deployment.yaml):

k8s.element.io/matrix-authentication-service-config-hash: sha1sum(configmap-data)
k8s.element.io/matrix-authentication-service-secret-hash: sha1sum(secret-data)

Ein geändertes Label ändert das Pod-Template — Kubernetes rollt also von selbst aus. Live vorhanden (drei Hash-Labels am MAS-Deployment). Und der HelmRelease steht auf interval: 1m, Flux liest valuesFrom also jede Minute neu ein und rendert bei Änderung neu.

Damit ist die Ursachenannahme des Issues zu korrigieren: Der Mechanismus fehlte nicht. Wahrscheinlicher ist, dass beim ADR-0011-Vorfall innerhalb des ersten Reconcile-Fensters geprüft wurde — „committet ≠ deployed" stimmt, aber die Lücke war zeitlich, nicht strukturell. Das ändert nichts an der Richtigkeit der ADR-0011-Regel (nach einem Sicherheits-Fix aktiv verifizieren), wohl aber an der Diagnose.

Abdeckung im Überblick (Hash-Labels am Pod-Template gezählt):

Abgedeckt	wodurch
MAS (3), element-web (2), haproxy (3), matrix-rtc (1–2)	ESS-Chart-Hash-Labels
coturn + Synapse (TURN-Secret)	eigener Mechanismus: der Rotations-CronJob hebt rotated-at/Checksum-Annotationen, der Merge startet beide Verbraucher neu (#38)

Nicht abgedeckt	konsumiertes Secret
draupnir	draupnir-config
wikijs	wikijs-postgres-secret
concierge-bot	concierge-credentials

Bewertung. Übrig bleiben drei Dienste mit Secrets, die sich selten und stets absichtlich ändern — anders als das monatlich rotierende TURN-Secret, das genau deshalb bereits einen eigenen Trigger hat. Ein zusätzlicher Controller (stakater/Reloader) bräuchte Rechte, Deployments zu patchen, und würde eine Dauerkomponente für ein Risiko einführen, das bei den wirklich bewegten Secrets bereits gelöst ist.

Empfehlung: nicht einbauen, sondern diese Abdeckungskarte als Ergebnis festhalten und die ADR-0011-Regel (aktiv verifizieren) für die drei Nachzügler gelten lassen. Wer anderer Meinung ist, hat mit Reloader einen sauberen Weg — die Chart erlaubt Annotationen je Komponente (matrixAuthenticationService.annotations, schema-geprüft), sie landen am Deployment und am Pod-Template.

Geschlossen 2026-08-15 — Entscheidung sorb: kein Reloader

Die Abdeckungskarte oben ist das Ergebnis; ein zusätzlicher Controller wird bewusst nicht eingebaut.

Begründung. Das Ziel des Issues — „Änderungen an einem konsumierten Values-Secret lösen automatisch einen Rollout aus" — ist für die Dienste, bei denen sich Secrets real bewegen, bereits erfüllt, nur anders als vermutet:

• MAS und die übrigen ESS-Komponenten über die Hash-Labels der Chart am Pod-Template (live verifiziert), zusammen mit interval: 1m am HelmRelease.
• coturn und Synapse über den rotated-at-Bump des Rotations-CronJobs — der einzige Fall mit regelmäßiger, unbeaufsichtigter Secret-Änderung, und genau deshalb schon gelöst (#38).

Übrig bleiben draupnir, wikijs und concierge-bot: Secrets, die sich selten und stets durch bewusstes Handeln ändern — also in dem Moment, in dem ohnehin jemand hinschaut und die ADR-0011-Regel (aktiv verifizieren) greift. Dafür einen Dauer-Controller mit Rechten, beliebige Deployments zu patchen, in die Produktion zu stellen, ist der schlechtere Tausch: bleibende Angriffsfläche und Wartungslast gegen ein Restrisiko, das genau dort klein ist, wo es zählt.

Das eigentliche Ergebnis dieses Issues ist die Karte, nicht der Einbau. Vorher wusste niemand, dass MAS abgedeckt ist — die Annahme war das Gegenteil, und ein Reloader wäre auf ein bereits gelöstes Problem gesetzt worden.

Falls die Entscheidung später kippt (etwa wenn ein Dienst dazukommt, dessen Secret automatisiert rotiert): Der Weg ist vorbereitet — die ESS-Chart erlaubt Annotationen je Komponente (matrixAuthenticationService.annotations, schema-geprüft), und sie landen sowohl am Deployment als auch am Pod-Template, also genau dort, wo stakater/Reloader sie liest.