Navigiere sicher durch die Herausforderungen von Keycloak! In unserem ersten Beitrag der neuen Inforeihe „Häufige Probleme mit Keycloak“ nehmen wir uns der vielleicht wichtigsten Frage an: Wie kann ich einen Ausfall vermeiden?
⏱ Lesezeit: 4 Minuten
Drei häufige Probleme mit Keycloak
Willkommen im neuen Jahr und somit zum ersten Beitrag unserer neuen Blogreihe: „Häufige Probleme mit Keycloak“. Heute beschäftigen wir uns damit, wie wir verhindern können, dass Keycloak zum Single Point of Failure wird.
Verhindern, dass Keycloak zum Single Point of Failure wird
Keycloak zeichnet sich insbesondere durch seine Fähigkeit aus, die Sicherheit von Web-Anwendungen zu gewährleisten und darüber hinaus das Benutzermanagement zu übernehmen. Als fester Bestandteil unseres Sicherheitssystems ist seine Zuverlässigkeit von größter Bedeutung. Keycloak funktioniert aus unserer Erfahrung sehr zuverlässig und reibungslos. Fällt es jedoch einmal aus, kann der Zugriff auf die damit verbundenen Applikationen blockiert werden, was im schlimmsten Fall zu erheblichen Ausfällen und Einnahmeverlusten führen kann.
Folgende Tipps sollen dabei helfen, den Keycloak-Betrieb einfach und stabil zu ermöglichen.
Problemherd: Datenbank
Auf der technischen Seite benötigt Keycloak eine persistente Datenbank für die dauerhafte Benutzerspeicherung. Wird Keycloak z.B. mit dem Standard Image von Dockerhub betrieben, wird standardmäßig eine In-Memory-Datenbank verwendet. Hierbei gehen jedoch alle Daten verloren, wenn der Container neu gestartet wird. Selbst wenn Benutzer per User Federation z.B. aus einem Active Directory eingebunden werden, ist die Nutzung einer persistenten Datenbank sehr ratsam, um die Möglichkeit zur Multifaktor-Authentifizierung zu aktivieren.
Viele Hoster bieten gemanagte Datenbanken an, darunter Postgres oder MariaDB, die sich beide gut mit Keycloak vertragen. Wenn die Datenbank selbst betrieben wird, empfehlen wir für Docker-Umgebungen MariaDB, da hier ein performanter Clusterbetrieb einfacher realisierbar ist. Für Kubernetes gibt es Helm Charts von Bitnami, die gleichzeitig eine Postgres DB mit hochfahren.
Problemherd: Hochverfügbarkeit
Wie hoch die Anforderungen an die Ausfallsicherheit sein sollen, hängt immer auch vom Einsatzszenario ab. Mindestens sollte in diesem Szenario aber eine Testumgebung zur Verfügung stehen, damit vor Updates geprüft werden kann, ob das Zusammenspiel aller beteiligten Komponenten weiterhin reibungslos funktioniert. Eine einfache Alternative wäre der Einsatz von Keycloak in einem Standalone Clustered Mode, z.B. auf Basis von Docker, der ein höheres Maß an Sicherheit bietet als Single Host-Betriebe.
Aber wie stellen wir sicher, dass auch diese Systeme widerstandsfähig bleiben? Eine Lösung besteht darin, zwei virtuelle Maschinen in verschiedenen Availability-Zonen (AZs) zu betreiben, um die Ausfallsicherheit zu erhöhen. In diesem Szenario kann als Datenbank eine gemanagte Datenbank des Hosters zum Einsatz kommen, die sich in beide AZs synchronisiert. Alternativ kann aber auch ein Maria DB Galera Cluster verwendet werden, der sich einfach als Docker Container parallel zu jedem Keycloak mitinstallieren lässt.
Steht Kubernetes zur Verfügung, ist auch hier der Betrieb im „Standalone Clustered Mode“ empfehlenswert und bringt zunächst alle Vorteile von Kubernetes mit sich. Bei vielen Anbietern lassen sich Kubernetes Cluster auch über mehrere AZs hinweg aufsetzen.
Problemherd: Skalierbarkeit
Die Anforderungen an die Skalierbarkeit von Keycloak hängen stark vom Verhalten der Benutzer und dem Verwendungszweck ab. Wie ist das Anmeldeverhalten der Benutzer? Melden sich die Benutzer gleichmäßig über den Tag verteilt an? Wie lange darf eine Benutzersession gültig bleiben?
Im Falle einer App ist es beispielsweise erstrebenswert, Benutzer mit Offlinetokens auszustatten, um zu verhindern, dass bei gelegentlicher Nutzung der App jedes Mal eine Anmeldung erforderlich ist. Jeder Benutzer meldet sich also im Grunde genommen nur einmal an, und die Überprüfung der Offlinetokens erfolgt bei Nutzung der App. Die Last verteilt sich dabei vermutlich breit über den Tag und die Woche.
In geschäftlichen oder B2B-Szenarien konzentriert sich der Benutzer-Login oft auf wenige Morgenstunden. In diesen Fällen ist der Einsatz von Keycloak in einem Kubernetes-Cluster mit Autoscaling-Funktion besonders effektiv. Bei dieser Technik werden bei bestimmter Auslastung (CPU/Memory) automatisch weitere Knoten hinzugefügt und bei Bedarf wieder heruntergefahren, um die Effizienz zu erhöhen.
Darüber hinaus ist es immer ratsam, Lasttests durchzuführen, um die richtige Dimensionierung deines Keycloak-Setups zu validieren oder die korrekte Autoskalierung in Kubernetes zu überprüfen. Auf GitHub gibt es dazu ein Gatling-basiertes Projekt, das eine gute Grundlage für solche Lasttests bietet.
Fazit
Abschließend lässt sich sagen, dass Keycloak eine leistungsfähige und zuverlässige Lösung für die Sicherheit von Web-Anwendungen darstellt. Eine sorgfältige Konfiguration, gepaart mit einer geeigneten Ausfallsicherheits- und Skalierungsstrategie, ist jedoch entscheidend, um das Risiko eines Single Point of Failure zu minimieren. Da der Betrieb von Keycloak gerade bei hohen Lasten nicht ohne Tücken ist, ist es ratsam, den Betrieb im Zweifel den Experten zu überlassen. Gerne kannst du dich bei uns auch für Hilfe bei konkreten Keycloak-Problemen melden.
Im nächsten Blogbeitrag werden wir tiefer in spezifische Probleme und deren Lösungsansätze eintauchen. Bleib dran, um zu lernen, wie du deine Web-Anwendungen noch sicherer machen kannst!
