Keycloak-SSO mit Docker Compose und Nginx

Keycloak-SSO einrichten: Docker Compose und Nginx verwenden

• Keycloak ist Open Source und eine zuverlässige Identity- und Access-Management-Lösung, die mit den wichtigsten SSO-Protokollen kompatibel ist.
• Die Einrichtung mit Docker Compose ist nicht kompliziert, aber nicht intuitiv, daher wird der Konfigurationsprozess zusammengefasst dargestellt.

Konzept

• Verwendet wird ein Standard-Setup, bei dem Nginx als zentraler Reverse Proxy dient und den Traffic über localhost an einzelne Services weiterleitet.
• Dies gilt als kostengünstiges Setup, das Umgebungen möglichst gut isoliert, während die Ressourcen eines einzelnen Hosts gemeinsam genutzt werden.

Voraussetzungen

• Benötigt werden grundlegende Werkzeuge (SSH, eine VM mit installiertem Linux, eine Domain oder Subdomain).
• Für ein Rootless-Docker-Setup wird ein neuer passwortloser Non-Root-Benutzer keycloak erstellt, die Bereiche in /etc/subuid und /etc/subgid werden aktualisiert, Rootless Docker wird installiert und der automatische Start des Dienstes konfiguriert.

Keycloak-Konfiguration

• Man meldet sich als neu erstellter Benutzer keycloak an und erstellt Verzeichnisse für persistente Daten und Docker-Dateien.
• Unter Bezug auf die offizielle Dokumentation wird eine docker-compose.yml erstellt, und in der Datei .env werden sensible und veränderliche Informationen eingetragen.

Lokal testen

• Der Docker-Compose-Stack wird getestet, ein Reverse-SSH-Tunnel zur VM erstellt und anschließend im Browser der Keycloak-Willkommensbildschirm geprüft.

Nginx-Konfiguration

• Nginx wird als systemweiter Reverse Proxy eingerichtet und eine neue Nginx-.conf-Datei für den Keycloak-Service erstellt.
• Beim Domain-Registrar wird ein A-Record hinzugefügt, damit DNS-Anfragen an die IP der VM weitergeleitet werden.

Debugging

• Man öffnet .tld.com, meldet sich bei Keycloak als Admin-Benutzer an und prüft die Docker-Compose-Logs sowie die Access- und Error-Logs von Nginx.
• Falls nötig, wird auch die Keycloak-Datenbank überprüft.

Benutzerdefinierter Build mit Dockerfile

• Statt das vorgefertigte Image von quay.io zu verwenden, wird mit einem Dockerfile ein eigenes Image gebaut.
• Docker Compose wird neu gestartet, um das Image zu bauen und den Service zu starten.

Fazit

• Der Keycloak-Service läuft hinter einem systemweiten Nginx-Reverse-Proxy mit Rootless Docker.
• Nächste Schritte sind automatische Updates für Docker-Container, das Hinzufügen von Login und E-Mail für den Keycloak-Service, das Hinzufügen von Realms sowie das Hinzufügen von Themes.

GN⁺-Meinung:

• Wichtigkeit von Sicherheit: Der aktuelle Zustand des Webs macht es schwer, mit sicherheitsrelevanten Schwachstellen Schritt zu halten, daher ist es wichtig, eine zuverlässige Lösung wie Keycloak zu verwenden.
• Effiziente Architektur: Die gemeinsame Nutzung von Ressourcen auf einem einzelnen Host bei gleichzeitiger Isolierung der Umgebungen ist kosteneffizient und leicht zu verwalten.
• Anpassbarkeit: Ein benutzerdefinierter Build mit Dockerfile bietet die Flexibilität, Keycloak an die eigenen Anforderungen anzupassen.

[GN⁺]

Hacker-News-Kommentare

• Meinung eines Nutzers, der sich für Authelia entschieden hat:

  • Keycloak bietet viele Funktionen, ist aber kompliziert zu konfigurieren und benötigt zusätzliche Services.
  • Authelia hat keine Benutzeroberfläche und unterstützt keine bidirektionale Synchronisierung mit einem LDAP-Server, lässt sich aber per statischen Dateien und Umgebungsvariablen konfigurieren und passt daher in vielen Fällen gut.
  • Wenn man nur einfache Authentifizierung und SSO braucht, wird ein Einstieg mit Authelia empfohlen.

• Meinung eines Nutzers mit Erfahrung mit JetBrains Hub und Keycloak, der sich für Dex entschieden hat:

  • JetBrains Hub lässt sich sehr einfach konfigurieren, das Fehlen eines latest-Tags für das Docker-Image ist aber unpraktisch.
  • Keycloak ist im Entwicklungsmodus einfach, die Konfiguration in einer echten Produktionsumgebung ist jedoch schwierig.
  • Am Ende fiel die Wahl auf Dex, obwohl die Dokumentation schwach ist, weil die Konfiguration einfach ist.
  • Durch die Kombination von OAuth2 Proxy und Nginx-Templates wurde die SSO-Konfiguration vereinfacht.
  • Für zusätzliche Sicherheit wurden Cloudflare Access und WAF ergänzt.

• Meinung eines Nutzers, der eine Vergleichstabelle für OpenID-Connect-Server erstellt hat:

  • Er war von der Größe der Keycloak-Codebasis überrascht.

• Meinung eines Nutzers zu Sicherheitsproblemen bei Keycloak:

  • Ein Blick auf die CVEs von Keycloak weckt Bedenken hinsichtlich der Sicherheit.

• Meinung eines Nutzers, der Erfahrungen mit einer Keycloak-Implementierung auf AWS ECS geteilt hat:

  • Keycloak hat über einen langen Zeitraum hinweg viele Veränderungen durchlaufen.
  • Es gab Schwierigkeiten beim Clustering, insbesondere bei der DNS-Erkennung und der Cluster-Erkennung über UDP.
  • Zustandsbehaftete Logins waren zwischen Servern nicht konsistent, was Load Balancing erschwerte.

• Meinung eines Nutzers mit einer positiven Erwähnung von Keycloakify:

  • Keycloakify scheint eine hervorragende Alternative zu Keycloak zu sein.

• Meinung eines Nutzers, der Authelia und Keycloak verglichen hat:

  • Authelia wirkt attraktiv, aber Keycloak erleichtert den Einstieg durch einen Angular-Connector.

• Meinung eines Nutzers, der seine Erfahrungen mit Keycloak geteilt hat:

  • Keycloak ist komplex in der Konfiguration und schwach dokumentiert, lässt sich mit Terraform aber einfach bereitstellen und verwalten.

• Meinung eines Nutzers, der Zitadel ausprobiert hat:

  • Keycloak kann für Einsteiger verwirrend sein, während Zitadel einfacher zu verwenden ist.

• Meinung eines Nutzers, der die Schwierigkeiten bei der Nutzung von Keycloak geschildert hat:

  • Keycloak stellt keinen direkten Link zum Zurücksetzen von Passwörtern bereit; dies muss über die API abgewickelt werden.
  • Die Cluster-Konfiguration ist nicht einfach, und es gibt Einschränkungen bei Realms.
  • Ein sicheres Login-System selbst aufzubauen ist riskant oder schwierig.