Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

//

Keycloak-Konfiguration mit Terraform

2.3.2021 | 6 Minuten Lesezeit

Infrastructure as Code (IaC) ist heutzutage aus der modernen IT-Landschaft nicht mehr wegzudenken. Red Hat beschreibt den Begriff wie folgt:

Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes. With IaC, configuration files are created that contain your infrastructure specifications, which makes it easier to edit and distribute configurations. It also ensures that you provision the same environment every time.

Im Grunde geht es darum, die Infrastruktur nicht mehr über UIs „zusammenzuklicken“. Stattdessen wird sie in Form von deklarativen textbasierten Codebausteinen formuliert, sodass jederzeit ersichtlich ist, was genau konfiguriert wurde. Durch die Textform ist bei Verwendung eines Versionierungstools, wie zum Beispiel Git, jederzeit nachvollziehbar, was wann geändert wurde.

Terraform

Ein beliebtes Tool, um IaC umzusetzen, ist Terraform von Hashicorp. In Terraform beschreibt man Konfigurationen über sogenannte Ressourcen, die wiederverwendbare und konfigurierbare Bausteine darstellen. Diese Ressourcen können dann über Provider auf eine Zielumgebung angewendet werden. Es gibt viele verschiedene Provider, die eingebunden werden können. Ein klassisches Anwendungsgebiet sind automatisierbare Deployments als Kombination verschiedener Dienste und Infrastrukturkomponenten in einer Cloud wie zum Beispiel Azure, AWS oder auch GCP. Neben der Provisionierung von Cloud-Ressourcen bietet Terraform auch die Möglichkeit, zahlreiche Anwendungen und Dienste zu konfigurieren. So wird Terraform für die Konfiguration verschiedener Anwendungen verwendet. In diesem Artikel nutzen wir Terraform, um eine Keycloak-Instanz zu konfigurieren. 

Keycloak

Keycloak ist eine Open-Source-Identity- und Access-Management-(IAM-)Lösung, welche die Standards OpenID Connect, OAuth 2.0 und SAML 2.0 unterstützt. Der Einsatz von Keycloak bietet den Vorteil, dass sich Entwickler nicht selbst um die Implementierung klassischer IAM-Features wie User Management, Login, Registrierung oder auch die „Passwort-vergessen“-Funktionalität kümmern müssen. Damit lassen sich eigene Anwendungen leicht um einen zentralen Login erweitern, der Single Sign-On (SSO) unterstützt. Zusätzlich bietet Keycloak einen starken Fokus auf Sicherheit und weist eine robuste Implementierung auf. Ein vergleichbares Sicherheitsniveau kann im Falle einer eigenen Implementierung der oben genannten Funktionalitäten nur unter verhältnismäßig hohem Aufwand aufgebaut werden. 

In diesem Beispiel werden ein Realm und ein Client angelegt, um die grundlegende Verwendung von Terraform für Keycloak zu verdeutlichen. Ein Keycloak-Realm ist eine Art Container für Benutzer, Anwendungen und Login-Verfahren. Realms stellen die oberste Ebene dar, auf der Keycloak logisch unterteilt werden kann. Im einfachsten Fall gibt es in einem Projekt einen Realm für die gesamte Anwendungslandschaft in einer Umgebung. Es lassen sich jedoch auch komplexere Strukturen über Realm-Beziehungen abbilden. Abhängig von den jeweiligen Anforderungen ist auch ein Multi-Realm-Setup möglich. Innerhalb eines Realms sind die geschützten Anwendungen als Clients hinterlegt. Ein Client kann hierbei je nach Art der Anwendung unterschiedlich gestaltet sein. In einer modernen Microservice-Architektur gibt es in der Regel eine Vielzahl von Services. Häufig bietet es sich an, pro Service einen dedizierten Client zu definieren. Diese Clients können dann so konfiguriert werden, wie die Anforderungen des jeweiligen Services es erfordern (z. B. eine mobile App, ein Web-Frontend, ein Backend-Service).

Eine Basiskonfiguration von Keycloak mit Terraform ist einfach und schnell gemacht (vorausgesetzt, dass Docker und Terraform bereits installiert bzw. in der CI-/CD-Pipeline verfügbar sind 🙂). In unserem Beispiel läuft Keycloak lokal in einem Docker-Container, in dem wir mittels Terraform einen Realm verwalten wollen. Der Container kann allerdings auch in die Cloud deployt werden, sodass Keycloak aus dem Internet heraus erreichbar ist. Zunächst laden wir uns das Docker Image von Red Hats Docker Repository quay.io herunter und starten den Container, in dem Keycloak läuft.

docker run -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=secret -p 8080:8080 quay.io/keycloak/keycloak:12.0.3

Et voilà – schon läuft der Keycloak (im Docker-Container) und kann unter http://localhost:8080 erreicht werden. 

Als nächstes erstellen wir einen Ordner keycloak-config in dem wir unsere erste Terraform Datei main.tf für die Konfiguration angelegen. Diese Datei bildet den zentralen Einstiegspunkt für unsere Terraform-Konfiguration. Im Kontext von Terraform stellt der Ordner ein Terraform-Modul dar, das wir mit entsprechenden Resource-Definitionen in Form von Terraform-Dateien ausstatten.

./keycloak-config/main.tf

In unserem Beispiel speichern wir den Zustand (Terraform State), den Terraform während der Provisionierung der Ressourcen erzeugt, lokal ab. Dies ist für lokale Testprojekte kein Problem, sollte aber in produktionsnahen Szenarien anders gelöst werden. 

In einem Produktiv-Szenario ist das Ablegen des Terraform States an einem zentralen Ort, z. B. einem AWS S3 Bucket oder einem GCP Storage Bucket, empfehlenswert. Der Terraform State enthält den Zustand aller von Terraform überwachten Ressourcen. 

Ein zentral verwalteter State erleichtert die Nutzung von Terraform in einer CI-/CD-Pipeline. Dabei ist zu beachten, dass Konflikte durch parallele Provisionierungen durch mehrere Entwickler oder Pipelines mittels State Locking verhindert werden müssen.

Außerdem ist es in einem realen Szenario empfehlenswert, die Terraform-Module übersichtlich zu strukturieren. Best Practices zur Strukturierung von Terraform-Projekten sind hier zu finden.

Folgendes passiert in dem Code

In dem hier gezeigten Use Case wird der Keycloak Terraform Provider eingebunden. Im Hintergrund verwendet der Provider die Keycloak Admin REST-API, um die Keycloak-Instanz zu konfigurieren. Dazu wird der Provider mit den Zugangsdaten der Keycloak-Instanz, die unter http://localhost:8080 läuft, initialisiert. Weitere Möglichkeiten zum Zugriff von Terraform auf Keycloak findet man hier .

Achtung! Im Beispielcode sind das Passwort und der Username hard-coded enthalten, um das Beispiel so kurz und anschaulich wie möglich zu halten. In einem realen Produktions-Setup sollte man aus Sicherheitsgründen keine Passwörter in Konfigurationsdateien verwalten. Stattdessen wird empfohlen, ein entsprechendes Secret Management zu verwenden. Beispielsweise können die Credentials über Terraform-Variablen hereingereicht werden. Die CI-/CD-Pipeline befüllt dann diese Variablen.

Im Folgenden erstellen wir für unser Beispiel einen Realm und einen Client. Viele Möglichkeiten, Keycloak mit Terraform zu konfigurieren, sind in der Dokumentation des Providers zu finden. Es sei hier jedoch angemerkt, dass nicht alle Features von Keycloak unterstützt werden. Beispielsweise kann man Stand heute (terraform 2.2.0) keine Default Realm Roles mit dem Terraform Provider definieren.

Momentan ist in dem Keycloak nur der Master Realm zu sehen. Das ändert sich, sobald wir unser Terraform Script anwenden. Dazu gehen wir nach dem klassischen Terraform Workflow vor.

terraform init

terraform init initialisiert Terraform in unserem Ordner. Dabei analysiert Terraform unsere Konfiguration und lädt etwaig benötigte Provider nach.

terraform validate

Nachdem unser Projekt initialisiert ist, bietet es sich an, mit terraform validate die Syntax unserer Konfiguration zu prüfen.

terraform plan -out=local.plan

Dann zeigt terraform plan eine Übersicht dessen, was konfiguriert werden würde, wenn terraform apply aufgerufen würde. Das ist wichtig, weil so sichergestellt werden kann, dass genau die gewünschte Konfiguration angewandt wird. So werden eventuelle Konflikte durch unterschiedliche Konfigurationszustände (States) verhindert. Sollte sich der State zwischen terraform plan und terraform apply ändern, kann das zu Problemen beim Anwenden der Konfiguration führen. So eine Situation kann zum Beispiel durch die gleichzeitige Verwendung mehrerer Benutzer auftreten.

terraform apply -input=false local.plan

terraform apply führt schließlich die Konfiguration aus. Der Parameter -input=false sorgt dafür, dass das Anwenden der Terraform-Skripte ohne manuelle Bestätigung durchläuft. Dies ist für die Verwendung in einer CI-/CD-Pipeline besonders wichtig.

Nun sind der neue Realm und Client im Keycloak unter http://localhost:8080 zu sehen – fertig!

Fazit

Terraform ist ein Tool für IaC mit umfangreicher Unterstützung für die Provisionierung von Cloud-Ressourcen und -Anwendungen. Die Verwendung des Keycloak Terraform Providers ist relativ einfach und ermöglicht die flexible Verwaltung von Realm-Konfigurationen, die sich gut in CI-/CD-Pipelines integrieren lässt. Damit lassen sich robuste und wartbare Realm-Konfigurationen erzeugen und verwalten.

Dieser Artikel wurde mit freundlicher Unterstützung von Thomas Darimont erstellt. In seinem GitHub-Account sind viele Beispiele u. A. zum Thema Keycloak zu finden.

Beitrag teilen

Gefällt mir

0

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.