docs: Gates 3 and 4 for the Authentik step — our own config would roll us back
The HelmRelease carries upgrade remediation with three retries and no strategy. The Flux CRD says the strategy defaults to rollback, that remediation runs between each attempt, and that the last failure is remediated too whenever retries exceed zero. A failing upgrade would therefore roll Helm back to the old version up to four times, against a database Django has already migrated forward — the exact inconsistency the documentation warns about, triggered by our own configuration. Disarming it comes before the version change, in its own commit. The two gates are merged deliberately: one file, one line, no signatures. The substance is the verification, and a health endpoint is not part of it beyond saying the process lives. The only check that counts is a real login through Element, MAS and Authentik — the same confusion between liveness and usability cost hours this morning.
This commit is contained in:
Thore Cimbal
@@ -86,7 +86,7 @@ Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md).
|
||||
|
||||
| Design | Gate | Title |
|
||||
|---|---|---|
|
||||
| [2026-08-21-cve-remediation](docs/design/2026-08-21-cve-remediation.md) | gate-2 | Design: Den CVE-Bestand abarbeiten (#0051) |
|
||||
| [2026-08-21-cve-remediation](docs/design/2026-08-21-cve-remediation.md) | gate-4 | Design: Den CVE-Bestand abarbeiten (#0051) |
|
||||
|
||||
## ADRs (27)
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
type: design
|
||||
status: gate-2
|
||||
status: gate-4
|
||||
date: 2026-08-21
|
||||
size: L
|
||||
related:
|
||||
@@ -282,3 +282,101 @@ alle Nutzer müssen sich neu anmelden.
|
||||
- Die übrigen 18 laufenden Images aus Haufen A.
|
||||
|
||||
> **STOP — Freigabe für Gate 2.**
|
||||
|
||||
> **Gate 2 freigegeben durch sorb, 2026-08-21**, samt Freigabe für **beide
|
||||
> Stufen** (2026.5.6 und 2026.8.0).
|
||||
|
||||
## Gate 3 + 4 — Program Design und Slices
|
||||
|
||||
**Zusammengelegt, mit Begründung:** Gate 3 verlangt Dateiorte, Signaturen und
|
||||
Aufrufwege. Hier gibt es eine Datei, eine Zeile und keine Signaturen — die
|
||||
Substanz dieses Vorhabens liegt in den Prüfpunkten und im Rückweg, also in
|
||||
Gate 4. Beides getrennt aufzuschreiben erzeugte zwei halbleere Abschnitte.
|
||||
|
||||
### Dateien
|
||||
|
||||
| Pfad | Änderung |
|
||||
|---|---|
|
||||
| `gitops/apps/authentik/authentik.yaml` Z. 11 | `version: "2026.2.3"` → `2026.5.6` → `2026.8.0` |
|
||||
| dieselbe Datei, `spec.upgrade.remediation` | `retries: 3` → `0` für die Dauer des Sprungs, danach zurück |
|
||||
|
||||
Sonst nichts. Keine Werte, keine Blueprints, kein Postgres.
|
||||
|
||||
### ⚠️ Der Fund, der die Reihenfolge bestimmt: Flux würde selbsttätig zurückrollen
|
||||
|
||||
Der HelmRelease trägt `upgrade.remediation.retries: 3` **ohne** `strategy`. Die
|
||||
Flux-CRD sagt dazu wörtlich:
|
||||
|
||||
```
|
||||
strategy: Defaults to 'rollback'
|
||||
retries: Remediation, using 'Strategy', is performed between each attempt
|
||||
remediateLastFailure: Defaults to 'false' unless 'Retries' is greater than 0
|
||||
```
|
||||
|
||||
Mit `retries: 3` ist damit **auch die Behebung des letzten Fehlschlags scharf**.
|
||||
Ein misslingendes Upgrade würde bis zu viermal auf **2026.2.3 zurückgerollt** —
|
||||
gegen eine Datenbank, die Django bereits nach vorne migriert hat. Das ist genau
|
||||
der Zustand `migration inconsistency`, vor dem die Anleitung warnt, und er würde
|
||||
**von unserer eigenen Konfiguration ausgelöst**.
|
||||
|
||||
Für ein Upgrade ohne Datenbank-Migration ist diese Einstellung richtig. Für
|
||||
dieses ist sie gefährlich, und deshalb steht ihre Entschärfung **vor** der
|
||||
Fassungsänderung, in einem eigenen Commit.
|
||||
|
||||
### Was die Prüfung zusichert
|
||||
|
||||
Je Stufe, in dieser Reihenfolge — die letzte Zeile ist die einzige, die zählt,
|
||||
wenn eine der vorherigen täuscht:
|
||||
|
||||
1. Worker-Protokoll: Migrationen gelaufen, **kein** `migration inconsistency`.
|
||||
2. `server` und `worker` bereit, beide auf der Zielfassung.
|
||||
3. `/-/health/ready/` antwortet 200.
|
||||
4. Blueprints angewandt, Flows und Provider unverändert vorhanden.
|
||||
5. **Eine echte Anmeldung durch die ganze Kette Element → MAS → Authentik.**
|
||||
6. Nach dem nächsten Scan-Durchlauf: Authentik-Image von 27 auf 5 CRITICAL.
|
||||
|
||||
⚠️ Punkt 3 allein genügt **nicht**. Ein Health-Endpunkt sagt, dass der Prozess
|
||||
lebt — nicht, dass ein Nutzer hineinkommt. Genau diese Verwechslung hat heute
|
||||
Vormittag Stunden gekostet.
|
||||
|
||||
### Slices
|
||||
|
||||
**Slice 0 — die selbsttätige Rückrollung entschärfen.** `retries: 3` → `0`.
|
||||
Kein Verhaltensunterschied im Normalbetrieb; wirkt nur im Fehlerfall. Verify:
|
||||
`kubectl get helmrelease -n authentik authentik -o jsonpath='{.spec.upgrade.remediation.retries}'` = `0`.
|
||||
|
||||
**Slice 1 — Sicherung von Hand.** `kubectl create job --from=cronjob/authentik-backup`.
|
||||
Verify: Job erfolgreich, Archivgröße im Protokoll plausibel (~166 MB).
|
||||
⚠️ Ohne diesen Schritt beginnt Slice 2 nicht.
|
||||
|
||||
**Slice 2 — 2026.2.3 → 2026.5.6.** Fassungszeile, Commit, Push; Flux zieht
|
||||
binnen einer Minute (`authentik-apps`, Intervall 1m). Danach Prüfpunkte 1–6.
|
||||
|
||||
**Slice 3 — 2026.5.6 → 2026.8.0.** Dieselben Schritte. Erst nach vollständig
|
||||
grünem Slice 2, nicht parallel.
|
||||
|
||||
**Slice 4 — `retries` auf `3` zurück.** Der Normalbetrieb soll die Behebung
|
||||
wieder haben; sie war nur für die Migrationsfenster falsch.
|
||||
|
||||
### Grenzen — DO NOT CHANGE
|
||||
|
||||
- `spec.values` und `valuesFrom` des HelmRelease — keine Konfigurationsänderung
|
||||
im selben Eingriff, sonst ist eine Störung nicht zuzuordnen.
|
||||
- `authentik-blueprints.yaml`, `postgresql`, `authentik-backup.yaml`.
|
||||
- Alles außerhalb des `authentik`-Namensraums.
|
||||
|
||||
### Wackeligste Annahmen
|
||||
|
||||
1. ⚠️ **Dass die Migrationen von 2026.2 auf 2026.5 durchlaufen.** Belegbar erst
|
||||
im Vollzug. Deshalb Slice 1 vor Slice 2 und deshalb `retries: 0`.
|
||||
2. **Dass die Blueprints unverändert greifen.** Sie referenzieren Stufen über
|
||||
`!Find`; verschwindet eine Stufe upstream, schlägt das Blueprint fehl statt
|
||||
still zu wirken — das ist die gutartige Ausfallart, aber Prüfpunkt 4 muss sie
|
||||
sehen.
|
||||
3. **Dass 2026.5.6 wirklich die letzte 2026.5 ist.** Aus dem Chart-Index
|
||||
gelesen, nicht geraten — sollte zwischen Plan und Vollzug eine 2026.5.7
|
||||
erscheinen, ist sie zu nehmen, weil die Anleitung „latest minor" verlangt.
|
||||
4. **Dass der Scan-Nachweis (Punkt 6) am selben Tag kommt.** Die Runde läuft
|
||||
alle 24 h; der Beleg kann bis zum Folgetag dauern. Das ist kein Fehlschlag.
|
||||
|
||||
> **STOP — Freigabe für Gate 3+4.**
|
||||
|
||||
Reference in New Issue
Block a user