Obige Abbildung zeigt die Zielarchitektur, die wir erreichen wollten. Entwickler:innen / DevOps sollten nur mit einem Git Repository interagieren und niemals direkt am Cluster oder der laufenden Keycloak Instanz Konfigurationen vornehmen. Eine GitOps-Engine “überwacht” das entsprechende Git Repository und sorgt dafür, dass die Änderungen aus dem Git Repository in den Cluster übernommen werden. Zusätzlich werden Änderungen, die direkt im Cluster vorgenommen werden, sofort wieder rückgängig gemacht, damit Git Repository und Cluster immer im gleichen Zustand sind. Bei unserer Lösung gibt es eine kleine Ausnahme, wodurch wir auch nicht 100% der Anforderungen von GitOps erfüllen. Dazu später aber mehr.
- Keycloak - SSO
GitOps mit Keycloak
Vor einiger Zeit standen wir vor einer spannenden Herausforderung: Wie können wir Keycloak nahtlos in Kubernetes/Openshift-Umgebungen möglichst automatisiert ausrollen und betreiben? Unser Ziel war es, jegliche Konfiguration einer Keycloak-Instanz in einem Git-Repository abzulegen und sicherzustellen, dass diese automatisch im richtigen Cluster und der richtigen Stage ausgerollt wird. In diesem Blogartikel möchten wir unsere Reise und die entstandene Lösung detailliert vorstellen, von den ersten Schritten bis hin zu den Feinheiten der Implementierung.
Erster Ansatz
Obige Abbildung zeigt die erste Version unserer Architektur.
Git Repository
Inhalt: Das Git-Repository enthält die Konfigurationsdateien und Definitionen für die Keycloak-Instanz. Diese Dateien umfassen Custom Resource Definitions (CRDs) für Keycloak selbst sowie die Konfigurationen.
Rolle: Das Git-Repository dient als Single Source of Truth für die gesamte Keycloak-Konfiguration.
ArgoCD
Funktion: ArgoCD ist ein Continuous Delivery-Tool, das GitOps-Prinzipien implementiert. Es überwacht das Git-Repository und synchronisiert automatisch Änderungen in die Kubernetes- oder OpenShift-Cluster.
Aktionen: ArgoCD liest die Konfigurationsdateien aus dem Git-Repository und wendet sie auf den Cluster an. Es sorgt dafür, dass die im Repository definierten Zustände stets im Cluster umgesetzt sind.
Keycloak Operator
Funktion: Der Keycloak Operator ist eine Applikation, die im Cluster läuft und für die Verwaltung der Keycloak Instanzen verantwortlich ist. Er liest die CRDs (Custom Resource Definitions) und führt die entsprechenden Aktionen durch.
Aktionen: Wird eine CRD für einen neue Keycloak Instanz im Cluster deployed, reagiert der Operator darauf und kümmert sich darum, die gewünschte Keycloak Instanz aufzusetzen und zu konfigurieren.
Durch diesen automatisierten Workflow wird sichergestellt, dass jede Änderung in der Keycloak-Konfiguration im Git-Repository automatisch im Cluster reflektiert wird.
Zurück zum Anfang
Während der Implementierung dieser Architektur mussten wir leider feststellen, dass sich der Operator für Keycloak noch in einem sehr frühen Entwicklungsstadium befand und seine Funktionalität noch sehr limitiert war. Vor allem das Konfigurieren des Keycloaks mithilfe des Operators war nicht möglich. Also hieß es zurück zum Anfang und eine alternative Lösung suchen.
Da Keycloak über eine hervorragende API verfügt und es bereits mächtige Tools gibt, die diese API ansprechen, haben wir uns Gedanken darüber gemacht, wie wir diese Möglichkeiten in Verbindung mit GitOps nutzen können.
Finale Lösung
Im Gegensatz zur ersten Version wird die Konfiguration mittels Kubernetes Job und nicht mehr via CRD und Keycloak Operator eingespielt. ArgoCD bietet die Möglichkeit, Jobs erst nach einem erfolgreichen Sync zu triggern. Wird im Git Repository eine Konfiguration verändert, synced ArgoCD diese Änderungen und triggered nach dem erfolgreichen Sync einen Kubernetes Job welcher die keycloak-config-cli von adorsys verwendet um die Konfigurationen in die jeweilige Keycloak Instanz einzuspielen. Aus technischen und auch aus organisatorischen Gründen haben wir uns dazu entschieden, die Konfiguration von der Keycloak Instanz zu trennen und in zwei separate Repositories aufzuteilen.
Fazit
Diese Lösung hat sich als äußerst effizient und zuverlässig erwiesen. Alle Ressourcen werden zentral im Git-Repository verwaltet, was eine konsistente und versionskontrollierte Konfiguration ermöglicht. Änderungen im Repository, sei es das Hinzufügen oder Löschen von Konfigurationen, werden automatisch in die entsprechenden Kubernetes- oder OpenShift-Cluster synchronisiert. Dadurch können wir sicherstellen, dass die gewünschten Zustände stets eingehalten und umgesetzt werden. Diese Automatisierung reduziert den manuellen Aufwand erheblich und minimiert das Risiko von Konfigurationsfehlern, was zu einer stabilen und leicht wartbaren Keycloak-Umgebung führt.
Warum erfüllen wir jetzt aber nicht alle Anforderungen für GitOps?
Würde man sich direkt in der Keycloak Oberfläche anmelden und Konfigurationen ändern, würde ArgoCD das nicht mitbekommen und hätte keine Möglichkeit den Zustand des Clusters mit dem gewünschten Zustand im Git Repository herzustellen. Erst wenn das nächste Mal eine Konfiguration im Git Repository gepusht wird, würde ArgoCD einen neuen Post-Sync Job triggern und die manuellen Änderungen wieder zurücksetzen.
