Keycloak Konfiguration mit DevOps Prinzipien

Du magst lieber Video statt Text? Herbert hat diesen Talk bei einem Meetup der Keycloak User Group Austria gehalten.

Warum wollen unsere Kunden Keycloak customizen?  

Bei MediaKey war der Anspruch des Kunden, eine Usability Konzept umzusetzen und Sonderfunktionen wie eine Altersverifikation zu integrieren. 

Was bringt das, wenn man Keycloak wie eine Individualsoftware per CI/CD über Stages hinweg ausrollt?

Bei MediaKey verwenden wir derzeit noch aus Support Gründen RH SSO 7.6.x, also die Wildfly Variante. Für Login, Registrierung und Account Oberfläche wurden die Keycloak Themes an unsere Bedürfnisse angepasst. All das führte zu einigen Konfigurationsanpassungen während der Entwicklungszeit.

Es gibt 4 Umgebungen

• DEV bestehend aus 2 geclusterten Keycloaks. 
• ITU damit Kunden die Integration testen können.
• TEST bestehend aus 3 Keycloak für Lasttests wegen den hohen Lastanforderungen. 
• PROD für naja… Prod halt. PROD besteht ebenfalls aus 3 Keycloak, jedoch mit doppelten CPU/RAM Resourcen als TEST. 

Diese Umgebungen manuell zu konfigurieren kam für uns nicht in Frage. Speziell Realms in der TEST Umgebung wurden regelmäßig gelöscht, um einfach die angelegten Testuser wieder loszuwerden.

Welches Automatisierungstool man wählt, ist nicht weiter wichtig. Wir haben ähnliche Lösungen in Gitlab CI/CD und Argo Workflows gebaut. Da wir bei diesem Kundenprojekt noch in der Wildfly/EAP und VMs Welt sind, haben wir gepardecs JBSS Skripte verwendet um den EAP Teil von Keycloak zu konfigurieren und das Theming JAR zu deployen. Mit diesen Skripten werden unter anderem die Postgres Datasource oder die Caches für Clustering konfiguriert. Mit diesen Skripten konnte man allerdings nicht den Keycloak (Realms, Clients, etc.) konfigurieren. Keycloak verfügt über eine hervorragende API und das erkannte auch adorsys mit ihrer keycloak-config-cli. 

An dieser Stelle vielen Dank an dieses tolle, gut dokumentierte und gewartete Tool ❤️.

Mit der keycloak-config-cli ist es uns möglich, den Keycloak zu konfigurieren.

Unsere Pipelines bestehen aus:

• dem Build/Test des JAR (Theming und Logik)
• Upload auf Artifactory
• Installation des SSO auf Umgebung X inkl. Konfiguration des Wildfly Teiles
• Konfiguration des Keycloak selbst.

Wie bereits erwähnt, verwenden wir um Keycloak zu konfigurieren die keycloak-config-cli.

Dazu verwenden wir zu 62,5% GitOps.

Das in Punkt 4 Continuously Reconciled beschriebene, machen wir nicht (da haben wir es uns einfach gemacht und bis jetzt haben wir es auch nicht benötigt)

Auch pullen wir nicht automatisch bei Änderungen in der Konfiguration.

Die Definition der Realm, Clients, usw. liegt dabei in einem Gitlab Repository. Die Umgebungen sind in verschiedenen Branches abgebildet.

Je nachdem, welche Umgebung konfiguriert werden soll, wird der entsprechende Branch ausgewählt.

Die Konfiguration selbst ist als YAML abgelegt. Merge Request von einer Stage in die andere sind nicht vorgesehen, da die Konfigurationen doch recht unterschiedlich sind. Wenn wir die Stages vergleichen wollen, wird ein File Diff zwischen den Branches gemacht.

Es werden allerdings sehr wohl Merge Requests gemacht, und zwar z.B. dann, wenn eine Änderung nach PROD gemacht wird. Hier stellt sogar unser Product Owner diese Merge Request, um z.B. einen neuen Client hinzuzufügen.

Dieses Vorgehen macht Produktionsdeployments stress- und fehlerfrei.

Durch die Variable Substitution können Secrets leicht ausgelagert und müssen nicht in Git gespeichert werden. Wir verwenden die Variable Substitution auch für den Realm Namen. Der Realm Name muss in jedem Konfigurationsfile angegeben werden. Somit ist es sehr leicht, ein neues Realm mit allen benötigten Konfigurationen anzulegen. Besonders praktisch ist dies für unsere Lasttests.

Damit wir für unsere anderen Projekte das Rad nicht neu erfinden müssen und bewährtes weiterverwenden, halten wir uns an das gelernte Vorgehen. Bei einem anderen Kundenprojekt verwenden wir bereits Keycloak.X. Die API hat sich natürlich weiterentwickelt, so aber auch die keycloak-config-cli. Der Build ist anders, da ein Image für Openshift benötigt wird. Deployed wird über eine Gitlab CI/CD Pipeline und Helm. Die Konfigurationen sind wieder in Git hinterlegt und werden über die keycloak-config-cli eingespielt.

Für unseren eigenen gepardec Keycloak verwenden wir ArgoCD um die Konfiguration in den Cluster zu schreiben und einen Post Sync Job um diese Konfiguration gegen den Keycloak zu fahren, wieder mittels keycloak-config-cli.

Hat man am Anfang einen höheren Aufwand um das alles einzurichten -> Ja klar.

Je länger man im Projekt arbeitet, je mehr Konfigurationsänderungen man hat, je mehr Stages man hat, desto schneller holt man diese gut investierte Zeit wieder herein. Alleine, dass man Änderungen für PROD vorbereiten, reviewen und in Sekunden einspielen kann und dadurch keinen Stress hat, ist den Aufwand allemal wert.