Files

T

Thore CimbalandClaude Opus 4.8 f248c4f03c docs(issues): close #0043 , record the coverage map for #0044

#0043: the case-insensitive username policy is live and verified end to end —
present in the ConfigMap, mounted in the worker, applied by authentik on its own,
and bound to the prompt stage. It reads only prompt_data, since the stage runs
anonymously and that is exactly what the previous system policies died on.

#0044 turns out to be largely solved already, which the issue could not know: the
ESS chart hangs config and secret hashes on the pod template as labels, so MAS and
the other chart components do roll out on change, and coturn has its own annotation
bump driven by the rotation job. What remains are three services whose secrets
change rarely and deliberately — recommending against adding a controller for that.

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

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

4.3 KiB

Raw Blame History

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

type

status

created

milestone

priority

area

issue

0044

open

2026-08-11

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.

4.3 KiB Raw Blame History Unescape Escape