---
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.