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

42 lines
1.7 KiB
Markdown
Raw Normal View History

---
type: issue
id: "0044"
status: open
created: 2026-08-11
milestone: M5
priority: low
area: infrastructure
related: [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.