Authelia Restore Test Plan

Ziel

Nachweisen, dass die Authelia-Konfiguration aus dem produktiven Borg-Archiv in einer isolierten Testumgebung wieder lauffaehig ist und der HTTP-Health-Endpunkt antwortet, ohne dass dabei produktive Secrets, produktives Postgres oder produktiver SMTP-Versand beruehrt werden.

Bewusst nicht Teil dieses Tests:

Restore mit produktiven Authelia-Secrets. Der Test nutzt ausschliesslich Wegwerf-Werte fuer AUTHELIA_SESSION_SECRET, AUTHELIA_STORAGE_ENCRYPTION_KEY und AUTHELIA_STORAGE_POSTGRES_PASSWORD. SMTP- und Legacy-JWT-Env-Werte werden bewusst nicht gesetzt, damit Authelia keinen notifier.smtp-Block oder deprecated jwt_secret aus Env erzeugt.
SMTP-Realanruf an GMX. Die minimale Test-Konfiguration setzt nur den Filesystem-Notifier.
Forward-Auth gegen Traefik. Test laeuft nur auf 127.0.0.1:19091, keine Traefik-Route.
WebAuthn-/Duo-/OIDC-Identity-Provider-Endpunkte. Smoke prueft /api/health.
pg_restore des produktiven postgresql17-authelia.dump. Authelia verschluesselt Storage-Werte mit AUTHELIA_STORAGE_ENCRYPTION_KEY. Ein Restore mit produktiven Daten in eine Test-Instanz mit Wegwerf-Key schlaegt im Startup-Check by design fehl ("the configured encryption key does not appear to be valid for this database"). Frische des produktiven Dumps wird ueber check-restore-freshness.sh ueberwacht; Daten-Decrypt-Drill ist eine separate DR-Aufgabe und braucht eine eigene Sicherheits-Choreographie mit kontrollierter Schluessel-Verwendung. Beobachtet im Erstlauf 2026-06-03 (Commit-Reihe cacf77b..8d71dfb); seit dem 2026-06-03-Folgecommit ist der Dump-Restore explizit aus dem Smoke entfernt.

Quelle

Backup-Quelle: produktives Borg-Archiv (hetzner_borg_appdata_critical)
fachlich relevante Pfade im Archiv:
- local/appdata/authelia/config (verpflichtend)
- local/borg-dumps/latest/postgresql17-authelia.dump (existiert ggf. im Archiv; wird vom Smoke bewusst NICHT eingespielt, siehe oben)
produktive Secrets unter /mnt/user/appdata/secrets/authelia_*.txt werden nicht gemountet

Test-Ziel

Restore-Lab: /mnt/user/backups/restore-lab/authelia
Testdatenpfade:
- /mnt/user/backups/restore-lab/authelia/config (restaurierte Originalkonfiguration + configuration.yml.original)
- /mnt/user/backups/restore-lab/authelia/test-config (Runtime-Mount mit minimaler Test-configuration.yml)
- /mnt/user/backups/restore-lab/authelia/postgres (Test-Postgres-Datadir)
- /mnt/user/backups/restore-lab/authelia/dumps/latest/postgresql17-authelia.dump (falls extrahiert)
- /mnt/user/backups/restore-lab/authelia/test-config/notifier/notifications.txt (Filesystem-Notifier-Ausgabe)
Testcontainer:
- restoretest-authelia (Image-Pin wie Produktion)
- restoretest-authelia-postgres (postgres:18.4, gleiche Major wie shared Postgres)
Testport: 127.0.0.1:19091:9091
Report-Ziel: /mnt/user/backups/restore-reports/authelia-YYYY-MM-DD.md

Schutzregeln

produktive Pfade /mnt/user/appdata/authelia/* werden nicht beschrieben
produktive Secret-Dateien /mnt/user/appdata/secrets/authelia_*.txt werden nicht gemountet
produktive shared PostgreSQL 18 wird nicht angesprochen (test-config/configuration.yml definiert nur Test-Postgres)
echter SMTP-Versand wird nicht ausgeloest (test-config/configuration.yml definiert nur Filesystem-Notifier)
produktive Domain auth.kaleschke.info wird nicht uebernommen
Testcontainer publishen nur auf 127.0.0.1, keine LAN-/Tailscale-Bindung
Borg-Passphrase wird aus /mnt/user/appdata/secrets/borg_repo_passphrase.txt gelesen und nirgendwo geloggt

Geplanter Ablauf

Restore-Lab-Pfade leer anlegen
local/appdata/authelia/config aus dem aktuellsten Borg-Archiv extrahieren
minimale test-config/configuration.yml erzeugen; restaurierte Begleitdateien wie users_database.yml bleiben im Runtime-Mount, produktive externe Abhaengigkeiten werden nicht uebernommen; notifier auf Filesystem, ntp.disable_startup_check: true, storage auf Test-Postgres
Test-Postgres mit ops/restore-tests/authelia-compose.test.yml frisch hochfahren (keine Daten aus Dump - siehe Encryption-Key-Begruendung oben)
authelia config validate gegen test-config/configuration.yml laufen lassen
restoretest-authelia starten und HTTP-Health http://127.0.0.1:19091/api/health pollen
Report unter /mnt/user/backups/restore-reports/authelia-YYYY-MM-DD.md schreiben
Testcontainer stoppen und Restore-Lab bereinigen (--keep-data ueberschreibt)

Smoke-Test

Minimal erfolgreich:

Borg-Extract der Authelia-Config gelingt
Test-Postgres startet healthy
authelia config validate laeuft ohne Fehler durch
HTTP 200 auf /api/health innerhalb 120 s

Optional spaeter:

vollstaendigen Auth-Flow gegen Test-User aus users_database.yml durchspielen
WebAuthn-Endpunkt /api/secondfactor/webauthn pruefen
ForwardAuth-Pfad gegen Mock-Backend testen

Bekannte Komplikationen

Risiko	Beschreibung	Mitigation
Testkonfig-Schema-Drift	Authelia erwartet nach Upgrade andere Keys in der Minimal-Konfig	bei `config validate`-Fehler Test-Block im Skript anpassen
SMTP-Startup-Check blockiert Start	Wenn Authelia trotz `disable_startup_check` SMTP probiert	Container-Logs lesen, ggf. Notifier-Block weiter haerten
NTP-Lookup im Test-Netz	Container hat keinen DNS-Resolver fuer `time.cloudflare.com`	im Smoke per `ntp.disable_startup_check: true` deaktiviert
Storage-Encryption-Key vs. Dump	siehe "Bewusst nicht Teil dieses Tests" - der Smoke laeuft FRISCH ohne Dump	by design - Daten-Decrypt-Drill ist separate Aufgabe
identity_validation Schema-Drift	Aelteres/neueres Authelia-Schema erwartet andere Keys	Validate-Config Output lesen, ggf. Test-Block anpassen
users_database.yml mit produktiven Hashes	Daten werden ins Restore-Lab kopiert, aber niemals gemountet auf produktive Domain	OK; Testpfad ist isoliert, kein Browser-Zugang ueber LAN

Status

Skript- und Compose-Scaffold abgelegt am 2026-06-02
Erstlauf am 2026-06-03 erfolgreich: Config aus Borg, minimale Test-Konfiguration, frisches Test-Postgres, HTTP /api/health 200, Report /mnt/user/backups/restore-reports/authelia-2026-06-03.md
Fuer die Rotation vorgesehen: zweiter Samstag in geraden Monaten, 07:30

6.2 KiB Raw Blame History