Projekt Phoenyx – Teil 8: Die Festungspforte (Authentik & Proxy-Schutz)

Warum „nur“ ein Login nicht reicht

Wir haben in den letzten Teilen unsere Infrastruktur (Netzwerk, Traefik, Crowdsec) aufgebaut. Jetzt fehlt noch eine entscheidende Komponente: Die Identitätsverwaltung.

Viele Tutorials zeigen dir, wie du Authentik installierst, um dich damit bei Grafana oder Portainer einzuloggen (das nennt man SSO oder OAuth). Das ist toll, aber für den Anfang oft zu viel des Guten. Was wir dringender brauchen, ist Schutz für Anwendungen, die gar keine gute eigene Sicherheit haben.

Stell dir vor, du betreibst einen WordPress-Blog. Der Blog soll für alle lesbar sein. Aber der Admin-Bereich (/wp-admin) ist oft Ziel von Angriffen. Wäre es nicht genial, wenn Traefik diesen Bereich komplett verstecken würde, bis du dich bei Authentik ausgewiesen hast? Genau das bauen wir heute.

---

Schritt 1: Die Architektur verstehen

Authentik ist keine einzelne „.exe“-Datei. Es ist ein verteiltes System. Schauen wir uns die authentik-docker-compose.yml an, die wir vorbereitet haben.

Die Komponenten

• PostgreSQL: Authentik besteht auf einer Postgres-Datenbank. Es mag kein MariaDB. Da dies der einzige Dienst ist, der Postgres braucht, isolieren wir ihn im Netzwerk authentik-internal.
• Authentik Server: Das ist das Gehirn. Hier läuft die Admin-Oberfläche, hier werden Benutzer gespeichert und Policies verwaltet. Der Server entscheidet: „Darf User X rein?“
• Authentik Worker: Ein Hintergrund-Arbeiter, der Aufgaben wie E-Mail-Versand, Aufräumarbeiten oder LDAP-Sync erledigt.
• Redis (Deaktiviert): Normalerweise nutzt Authentik Redis als Zwischenspeicher (Cache). Für unser Setup (Single-Instance, wenige User) ist das Overkill. Wir haben es in der Config per AUTHENTIK_REDIS__ENABLED: 'false' deaktiviert, um RAM zu sparen. Postgres übernimmt diese Aufgaben.

Der „Outpost“ (Das Missverständnis)

Hier steigen die meisten Einsteiger aus. Authentik trennt die Entscheidung (Server) von der Durchsetzung (Outpost).

Der Authentik Server sitzt sicher in seinem Container. Er sieht den Traffic deiner Webseite gar nicht. Dafür gibt es den Outpost. Das ist ein kleiner, flinker Proxy-Container (basierend auf Nginx/Go), der direkt neben Traefik steht.

Der Ablauf einer Anfrage:

1. Besucher ruft mein-blog.de/wp-admin auf.
2. Traefik fängt die Anfrage ab.
3. Traefik fragt den Outpost: „Hey, da will einer zu /wp-admin. Ist der eingeloggt?“
4. Der Outpost prüft das Session-Cookie.
   • Nein: Outpost sagt Traefik: „Leite den User zur Login-Seite um.“
   • Ja: Outpost sagt Traefik: „Alles klar, lass ihn durch.“

---

Schritt 2: Die Installation (Docker Compose)

Wir starten unseren Stack. In der Datei /opt/containers/authentik/authentik-docker-compose.yml haben wir alles vorbereitet. Besonders wichtig ist der Abschnitt für den Outpost:

  # === Authentik Outpost ===
  authentik-outpost-traefik:
    image: ghcr.io/goauthentik/proxy:2025.10
    container_name: authentik-outpost-traefik
    # ...
    labels:
      # Hier definieren wir die "Magie" für Traefik
      - "traefik.http.middlewares.auth-traefik.forwardauth.address=http://authentik-outpost-traefik:9000/outpost.goauthentik.io/auth/traefik"
      - "traefik.http.middlewares.auth-traefik.forwardauth.trustForwardHeader=true"
      - "traefik.http.middlewares.auth-traefik.forwardauth.authResponseHeaders=X-Authentik-Username,X-Authentik-Email"

Was passiert hier?
Wir definieren eine Traefik-Middleware namens auth-traefik. Jedes Mal, wenn wir diese Middleware später einem anderen Container zuweisen, wird der Traffic erst an die Adresse http://authentik-outpost-traefik:9000... geschickt.

Starte den Stack nun (falls noch nicht geschehen) im Hauptverzeichnis:

cd /opt/containers
docker compose up -d

---

Schritt 3: Initiales Setup (Der erste Login)

Sobald die Container laufen, rufe deine Authentik-URL auf (z.B. https://auth.deine-domain.de/if/flow/initial-setup/). Dort legst du das Passwort für den Benutzer akadmin fest.

Danach landest du im Dashboard. Es wirkt erst einmal leer und kompliziert. Lass dich nicht abschrecken.

1. Gehe im Authentik Admin-Interface auf Applications -> Outposts.
2. Du siehst dort vermutlich schon einen Eintrag oder erstellst einen neuen (Typ: Proxy).
3. Klicke auf den Outpost und kopiere das Token.
4. Füge dieses Token in deine .env Datei ein: AUTHENTIK_OUTPOST_TOKEN=dein-langes-token.
5. Starte den Outpost-Container neu: docker compose up -d --force-recreate authentik-outpost-traefik.

Jetzt sollte im Authentik Dashboard beim Outpost ein grüner Haken („Healthy“) erscheinen. Die Verbindung steht!

---

Schritt 4: Einen „Proxy Provider“ erstellen

Damit Authentik weiß, was es schützen soll, müssen wir einen „Provider“ anlegen. In Authentik-Sprache ist ein Provider das Stück Logik, das entscheidet „Wie wird geschützt?“.

1. Gehe zu Applications -> Providers.
2. Erstelle einen neuen Provider vom Typ Proxy Provider.
3. Name: WordPress-Protection
4. Authorization flow: default-provider-authorization-implicit-consent (Das bedeutet: Wenn Login korrekt, leite sofort weiter ohne „Wollen Sie wirklich?“-Frage).
5. Forward Auth (Single Application): Hier trägst du die Domain deiner App ein, z.B. https://blog.deine-domain.de.

Schritt 5: Die Application erstellen

Ein Provider allein tut nichts. Er muss einer „Application“ zugewiesen werden.

1. Gehe zu Applications -> Applications.
2. Erstelle eine neue Application.
3. Name: Mein Blog Admin.
4. Provider: Wähle den eben erstellten WordPress-Protection Provider aus.

Der letzte Klick: Gehe zurück zu Applications -> Outposts. Bearbeite deinen Outpost und stelle sicher, dass rechts bei „Selected Applications“ deine neue App „Mein Blog Admin“ ausgewählt ist. Nur dann weiß der Docker-Container des Outposts, dass er für diese App zuständig ist.

---

Schritt 6: Den Schutz aktivieren (Traefik Labels)

Jetzt kommt der Moment der Wahrheit. Wir haben alles vorbereitet. Jetzt müssen wir unserem WordPress-Container nur noch sagen: „Benutze den Türsteher!“

Öffne die docker-compose.yml deines WordPress (oder Whoami, oder was auch immer du testen willst) und füge Labels hinzu.

Szenario A: Alles schützen

Wenn die ganze Seite hinter den Login soll:

labels:
  - "traefik.http.routers.wordpress.middlewares=auth-traefik"

Szenario B: Nur /wp-admin schützen (Profi-Variante)

Hier definieren wir ZWEI Router für denselben Container. Einen öffentlichen und einen geschützten.

labels:
  # Router 1: Öffentlich (Alles außer /wp-admin)
  - "traefik.http.routers.wp-public.rule=Host(`blog.de`)"
  - "traefik.http.routers.wp-public.entrypoints=websecure"
  
  # Router 2: Geschützt (Nur /wp-admin)
  # Wichtig: Die Regel ist spezifischer ("länger"), daher gewinnt sie für diesen Pfad
  - "traefik.http.routers.wp-admin.rule=Host(`blog.de`) && PathPrefix(`/wp-admin`)"
  - "traefik.http.routers.wp-admin.entrypoints=websecure"
  - "traefik.http.routers.wp-admin.middlewares=auth-traefik"  <-- HIER ist der Schutz!

Wenn du das deployest, passiert Folgendes:

• Gehst du auf blog.de, siehst du die Seite ganz normal.
• Klickst du auf blog.de/wp-admin, fängt Traefik dich ab. Die Middleware auth-traefik leitet dich zu Authentik um. Du musst dich einloggen. Erst dann wirst du zum WordPress-Admin-Panel durchgelassen.

---

Fazit

Wir haben jetzt ein extrem mächtiges Werkzeug. Wir können jeden Pfad jeder Anwendung schützen, selbst wenn die Anwendung selbst gar keine Benutzerverwaltung hat. Wir haben Authentik erfolgreich als "Forward Auth" Proxy vor unsere Dienste geschaltet.

Im nächsten und letzten Teil widmen wir uns der Datenhaltung: MariaDB und wie wir sie einfach verwalten.