Zum Inhalt

Authelia

Zentraler Identity Provider für die extern erreichbaren Dienste. Authelia authentifiziert gegen lldap und hängt als Forward-Auth-Schicht vor Traefik-Routern. GitHub

Stand 18.08.2026 — teilweise ausgerollt

Authelia und lldap laufen auf dem Server (auth. und ldap. antworten, /api/health meldet OK). Die Forward-Auth-Middleware ist aber noch nicht an den Routern: Ein Aufruf von uptime.homelab-external.robinwerner.net/dashboard antwortet direkt mit 200 statt auf das Login-Portal umzuleiten. Der zugehörige Stand liegt im Branch feat/forward-auth-hetzner-tools und ist noch nicht auf main. Umsetzungsrahmen: RFC-003.

URL auth.homelab-external.robinwerner.net
Backend lldap über ldap://lldap:3890
Speicher PostgreSQL (identity-postgres, Datenbank authelia)
2FA TOTP und WebAuthn, beide aktiv
Benachrichtigung SMTP über SMTP2GO

Kein SSO — eine Schicht davor

Uptime Kuma, Healthchecks und Headplane werten die von Authelia gesetzten Header (Remote-User, Remote-Groups, Remote-Email, Remote-Name) nicht aus. Sie behalten ihren eigenen Login. Authelia ist eine vorgelagerte Schutzschicht, kein Single Sign-on.

Der nächste Ausbauschritt wäre nativer OIDC für die Dienste, die ihn können — so vorgesehen in RFC-003.

Die zwei Regeln, an denen alles hängt

Beides bricht still, nicht laut

1. Ein Router ohne die authelia@file-Middleware ist ungeschützt — egal, was access_control sagt. Die Middleware entscheidet, ob überhaupt gefragt wird.

2. access_control entscheidet, was passiert, wenn gefragt wird. Mit default_policy: deny liefert jede Domain ohne passende Regel „Access denied" — und zwar nach erfolgreichem Login. Das sieht aus wie ein kaputter Login, ist aber eine fehlende Regel.

Die Reihenfolge der Regeln ist bindend: Authelia nimmt die erste passende. Alle bypass-Regeln müssen deshalb vor den two_factor-Regeln stehen.

Zugriffsregeln

Domain Pfad Wer Policy
auth.* alles bypass
hc.* ^/ping/.* Maschinen bypass
uptime.* Push-API, Status-Seiten, Assets, Icons Maschinen/anonym bypass
uptime.*, hc.* Rest hetzner-user two_factor
headscale.* ^/admin.* hetzner-admin two_factor
ldap.* alles hetzner-admin two_factor

Warum die Bypass-Regeln nötig sind

Maschinenverkehr hat keine Sitzung. Ohne Ausnahme landet er auf dem Login-Portal und stirbt lautlos:

  • Healthchecks-Cron-Pings (^/ping/.*, rund 35.000 Anfragen) — darunter die Meldungen des Borgmatic-Backups vom NUC. Ohne Bypass meldet das Backup-Monitoring stumm „down".
  • Uptime-Kuma-Push-Monitore (^/api/push/.*) — dieselbe Mechanik.
  • Status-Seiten samt Assets sollen anonym lesbar bleiben. Dafür braucht der Browser neben der Seite auch Heartbeat-API, Assets und Icons — sonst lädt sie leer.

Die Pfade sind gegen die Routen von Uptime Kuma 2.1.3 verifiziert, nicht geraten. Bewusst nicht freigegeben: /api/badge/*.

Die Headscale-Domain ist geteilt

headscale.homelab-external.robinwerner.net trägt sowohl die Headscale-VPN-API (/key, /ts2021, /api) als auch Headplane unter /admin.

Nur der Headplane-Router bekommt die Middleware

Die Domain als Ganzes zu schützen würde jeden VPN-Client aussperren — das Tailscale-Protokoll kann sich nicht an einem Login-Portal anmelden.

Fallstricke

resources matcht Pfad und Query-String

Ein Anker mit blossem $ (etwa ^/icon\.svg$) scheitert still an /icon.svg?v=2. Korrekt ist das dokumentierte Idiom ([/?].*)?$.

Authelia 4.39 hat kein authelia healthcheck-Kommando

Der Image-Default /app/healthcheck.sh ist ein No-op, solange X_AUTHELIA_HEALTHCHECK nicht gesetzt ist. Der Healthcheck ist deshalb eine wget-Probe gegen /api/health.

cap_drop: ALL + no-new-privileges verlangt user: \"1000:1000\"

Sonst versucht der Entrypoint chown und su-exec als root und scheitert. Alle gemounteten Pfade müssen dann UID 1000 gehören — einschließlich der Verzeichnisse selbst, nicht nur ihres Inhalts.

SMTP2GO-Benutzername ist <domain>-<name>

Also robinwerner.net-authelia, nicht die Mailadresse.

disable_startup_check steht bewusst auf false: Authelia testet SMTP beim Start (nur RCPT TO, es geht keine Mail raus). Schlägt der Test fehl, startet Authelia nicht — eine Fehlkonfiguration fällt sofort auf, statt erst beim ersten Passwort-Reset.

Sitzungen und Sperren

Einstellung Wert
Inaktivität 5 min
Ablauf 1 h
„Angemeldet bleiben" 1 Monat
Sperre nach 5 Fehlversuchen in 2 min
Sperrdauer 5 min

Secrets

Alle über *_FILE-Umgebungsvariablen aus /opt/homelab-data/secrets/, keines im Repo: LDAP-Bind-Passwort, Storage-Encryption-Key, JWT-Secret für den Passwort-Reset, SMTP-Passwort.