Ben Bajorat 02. Mai 2023

Keycloak – User Storage SPI

Keycloak ist eine Open-Source-Software-Lösung, die als Identity-and-Access-Management-System (IAM-System) verwendet wird. Keycloak ist abstrakt betrachtet eine Mensch-zu-Maschine-Schnittstelle für den Workflow der Authentifizierung und Autorisierung von Nutzern gegenüber einer Ressource.

Darüber hinaus ist es eine zentrale Plattform zur Verwaltung von Nutzern, Gruppen und Berechtigungen. Obwohl Keycloak auch unabhängig von dem IT-Sicherheitskonzept Zero Trust betrieben werden kann, bei dem jeder Zugriff authentifiziert und autorisiert werden muss, kann es ein wichtiger Bestandteil einer Zero-Trust-Architektur (ZTA) sein. Dabei würde es die Identitäts- und Zugriffsverwaltung in einem Netzwerk unterstützen und verwalten. Keycloak kann in einer ZTA dazu beitragen, dass sichere Authentifizierungsmethoden wie u. a. Multi-Faktor-Authentifizierung und Social-Login neben Benutzername und Passwort verwendet werden können, um den Zugriff auf Anwendungen und Ressourcen zu schützen [1].

Hinweis: Zero Trust ist ein Konzept für die Netzwerksicherheit, bei dem jeder Zugriff auf Ressourcen im Netzwerk authentifiziert und autorisiert werden muss, unabhängig davon, ob der Zugriff von innerhalb oder außerhalb des Netzwerks erfolgt. Dies bedeutet, dass Benutzer oder Geräte, die auf das Netzwerk zugreifen möchten, nicht automatisch als vertrauenswürdig betrachtet werden, sondern zuerst identifiziert und authentifiziert werden müssen, bevor sie Zugriff erhalten [1;2].

Keycloak bietet eine Single-Sign-On-Funktionalität (SSO), mit der Benutzer sich einmal anmelden können, um auf verschiedene Anwendungen zuzugreifen, ohne sich bei jeder Anwendung einzeln anmelden zu müssen. Auch Funktionen wie die Integration mit LDAP/AD-Verzeichnissen, Multi-Faktor-Authentifizierung, Rollen- und Berechtigungsmanagement sowie eine benutzerfreundliche Administrationsoberfläche, die seit dem Wechsel von WildFly auf Quarkus nun auch eine angenehmere User Experience (UX) bietet, gehören zum Setup.

Keycloak ist in Java implementiert und kann als Standalone-Server und/ oder als Docker-Image bereitgestellt werden. Letzteres findet ebenfalls in Kubernetes ein Zuhause. Es ist in vielen Anwendungs-Frameworks integriert und bietet SDKs und APIs für eine stabile Integration in Anwendungen. Das erste Release war 2015 verfügbar und wurde seitdem sukzessive weiter entwickelt.

Versionskonflikte

Gerade in jüngerer Zeit gab es einige Veränderungen in Releases, die nicht abwärtskompatibel mit älteren Versionen von Keycloak funktionieren. Insbesondere die Ablösung von WildFly durch Quarkus hat einige bahnbrechende Änderungen nach sich gezogen, die mit älteren Versionen nicht mehr vereinbar sind [3]. Beispielsweise gab es in der Version 19.0.0 u. a. bzgl. der Implementierung von Service-Provider-Interfaces (SPI) Abänderungen. Wird hier eine User-Federation für beispielsweise SQL verwendet, müssen die Java-Klassen, welche das Service-Provider-Interface dafür implementieren, stark angepasst werden. Darüber hinaus wird ab v19.0.0 Java 11 als Mindestanforderung voll unterstützt. Ältere Java-Versionen sind damit obsolet [4].

Auch die API zur Verwaltung und Monitoring von Anwendungen wurde verbessert und einige der bisherigen API-Endpunkte wurden geändert. Das betrifft insbesondere die Health-Endpoints, die seit der Einführung von Quarkus in v17.0.0 u. a. über einen Subpath q/health erreichbar waren und nun auf das additive Quarkus-q verzichten [4].

Die Funktion zur Verwaltung von Benutzer- und Gruppenrollen wurde dahingehend verbessert, dass diese Funktion durch eine neue rollenbasierte Zugriffskontrolle ersetzt wurde. Die Einstellungen bzgl. der Clients in Realms haben sich in v19.0.0 stark verändert. So werden beispielsweise Protocol-Mapper nicht mehr über einen Tab in der Clients-Sektion manipuliert, sondern müssen über die Client-Scopes zugeordnet werden [4;5].

Abb. 1: Bisherige Einstellungen: Client -> Mappers -> Create/Add Builtin

Abb. 2: Einstellungen ab v19.0.0: Client -> Client Scopes -> Setup -> Add client Scope / Search by Name

Ein Re-Import einer bestehenden realm.json aus einer älteren Version wird nicht ohne grobe Anpassung funktionieren. Im Übrigen gibt es neben den Keycloak Release-Notes einen hilfreichen Upgrade-Guide in der offiziellen Dokumentation [6]. Leider können Änderungen manchmal auch Probleme abseits von Kompatibilität nach sich ziehen [5].

Bekannte Schwachstellen und Gefährdungen

CVE-2022-1245[7] wurde am 28. Februar 2023 publiziert [8] und ist zum Erscheinen dieses Artikels die letzte registrierte Sicherheitslücke [9], die Keycloak aktuell betrifft. Sie ermöglicht es einem Angreifer, den Authentifizierungsprozess zu umgehen und unbefugten Zugriff auf geschützte Ressourcen über die Admin REST API in Keycloak zu erhalten. Das Problem wird als CWE-74 kategorisiert [10]. Die Schwachstelle ist auf einen Fehler in der Handhabung des Keycloak-Multi-Faktor-Authentifizierungs-Tokens (MFA) zurückzuführen. Ein Angreifer kann diese Schwachstelle ausnutzen, indem er das MFA-Token eines authentifizierten Benutzers stiehlt und damit Zugang zu geschützten Ressourcen erhält.

Die potentielle Sicherheitslücke erhielt eine CVSS-Punktzahl von 7,5 und ist damit eine Sicherheitslücke mittlerer Schwere. Die Lücke wurde von einem Sicherheitsforscher entdeckt und gemeldet. Ein Patch ist bereits veröffentlicht und ein Upgrade auf Keycloak v20.0.5 sollte die Lücke schließen.

Hinweis: Auf die Gefährdung wird beispielhaft Bezug genommen, um auf die leichte und umfangreiche Einsicht von Schwachstellen im Bezug auf Keycloak hinzuweisen, das Thread-Management von Keycloak zu thematisieren und Developer-Aktionen aufzuzeigen, die in solchen Fällen unternommen werden können.

Einstweilen kann die Konfiguration von Keycloak dahingehend angepasst werden, dass geeignete Sicherheitsmaßnahmen getroffen werden, wie z. B. die Beschränkung des Zugriffs durch autorisiertes Personal, die Einführung strenger Passwortrichtlinien und die Aktivierung der Zwei-Faktor-Authentifizierung (2FA). Aber um beispielsweise eine 2FA per SMS oder Email zu unterstützen, wird ein Custom Keycloak Email/SMS 2FA Authentication Provider benötigt, ein SPI [8].

Desweiteren lassen sich viele Plugins wie die Admin-REST-PI auch leicht (de-)aktivieren [11]. Dafür muss lediglich ein Parameter für die Installation von Keycloak hinzugefügt werden und der laufende Keycloak restartet werden, es gibt aber auch die Möglichkeit, dies im laufenden Betrieb auszuführen (s. a. Installation in Kubernetes).

Keycloak Service-Provider-Interfaces (SPI)

Bei einem Service-Provider-Interface handelt es sich um ein Konzept, das es Entwicklern ermöglicht, die Funktionalität von Keycloak zu erweitern oder anzupassen, indem sie eigene Implementierungen für bestimmte Schnittstellen bereitstellen, ohne dabei den Kerncode von Keycloak verändern oder erweitern zu müssen. Keycloak bietet eine Vielzahl von SPIs [12], die Entwickler verwenden können, um verschiedene Aspekte des Systems zu konfigurieren oder zu erweitern. Beispielsweise ermöglicht die bereits erwähnte User-Storage-SPI eigene Implementierungen, um den Zugriff auf Benutzerinformationen in Keycloak bereitzustellen [13].

Dabei ist Keycloak im Prinzip ein vorkonfigurierter Java Quarkus (ehem. WildFly) Application Server, der separat von Applikationen läuft, für die eine Autorisierung erforderlich ist. Die Anwendungen bzw. die Clients leiten die unauthentifizierten Nutzer zur Anmeldung an Keycloak weiter. Keycloak nimmt seinerseits die Anmeldeinformationen entgegen und versucht, den Benutzer zu authentifizieren und autorisieren. Dabei werden keine Nutzerdaten, sondern der Nutzer selbst vom Client/Applikation an Keycloak weitergeleitet. Somit ist die Anwendung von den Anmeldeinformationen der Benutzer isoliert. D. h. die Anwendung selbst interagiert weder mit den Anmeldeinformationen, noch ist sie an der Authentifizierung beteiligt. Dadurch reduziert sich nicht nur das Risiko, dass potenziell sensible Daten abgefangen werden könnten, Keycloak kann dadurch auch als zentrale Schnittstelle zur Authentifizierung von multiplen Applikationen (SSO) dienen [5].

Keycloak bietet zwei Standard-User-Provider (Kerberos; LDAP/ActiveDirectory(AD)) an, um Nutzer und Gruppen in Keycloak zu managen. Diese Provider benötigen kein Service-Provider-Interface – also keine manuell erweiterte Konfiguration mit zusätzlichem Code – und sind nach der Standardinstallation verfügbar. Die Provider sind im Menü unter User-Federation gelistet und können dort über eine Maske eingestellt und verdrahtet werden. Soll eine Nutzerverwaltung jedoch beispielsweise über eine SQL-Datenbank realisiert werden, ist ein spezielles SPI – eine erweiterte Funktionalität – notwendig. Diese muss zusätzlich implementiert und bei der Installation von Keycloak bereitgestellt werden [14].

Zum Zeitpunkt des Entstehens dieses Artikels muss eine erweiterte Funktionalität dieser Art mit der API des keycloak-model-legacy-Moduls beschrieben werden. Die Abweichungen der Module von Keycloak v19.0.0 zu vorhergehenden sind beispielhaft für die oben beschriebenen Versionskonflikte. Die Funktionalität der User-Provider-SPI soll laut RedHat zukünftig durch eine neue Map-Storage-API implementiert und ersetzt werden und ist zu diesem Zeitpunkt (März 2023) angekündigt, aber noch nicht verfügbar [4;14].

Implementierung einer User-Storage-SPI

Ein Service-Provider-Interface, das erweiterte Funktionalität bereithält, wird für Keycloak immer als zusätzliche .jar-Datei ausgeliefert. In dem Kapitel über Keycloak in Kubernetes ist exemplarisch dargestellt, wie diese Datei für den Installationsprozess eingebunden werden kann. Bestenfalls sollte das Modul in einem eigenständigen Projekt organisiert sein. Das Projektobjektmodell für die User-Storage-SPI wird nachfolgend mit Maven verwaltet. Bis Keycloak v19.0.0 waren für die Implementierung der User-Storage-SPI folgende dependencies in der pom.xml ausreichend:

Keycloak v18.0.0 SPI pom.xml:

    ...
    <properties>
        ...
        <keycloak.version>18.0.0</keycloak.version>
    </properties>
    
    <dependencies>
        <dependency>
            <groupId>org.keycloak</groupId>
            <artifactId>keycloak-core</artifactId>
            <version>${keycloak.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.keycloak</groupId>
            <artifactId>keycloak-server-spi</artifactId>
            <version>${keycloak.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.keycloak</groupId>
            <artifactId>keycloak-server-spi-private</artifactId>
            <version>${keycloak.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.keycloak</groupId>
            <artifactId>keycloak-services</artifactId>
            <version>${keycloak.version}</version>
            <scope>provided</scope>
        </dependency>
        ...
    <dependencies>
    ...

Ab Keycloak v19.0.0 und bzgl. des Hinweises in der Dokumentation für die User-Storage-SPI über die (noch) Absenz einer einheitlichen Map-Storage-API als Methode für den Zugriff auf lokale und externe Informationen über Benutzer und andere Entitäten, welche die alten (Legacy-)APIs obsolet machen, muss die pom.xml zu diesem Zeitpunkt nun um eine folgende weitere Abhängigkeit erweitert werden.

Keycloak v19.0.0 SPI pom.xml:

    ...
    <dependencies>
        ...
        <dependency>
            <groupId>org.keycloak</groupId>
            <artifactId>keycloak-model-legacy</artifactId>
            <version>${keycloak.version}</version>
        </dependency>
        ...
    <dependencies>
    ...

Nachfolgend soll beschrieben werden, inwiefern das keycloak-model-legacy-Modul exemplarisch genutzt werden kann, um die Methoden und Klassen bereitzustellen, damit eine User-Storage-SPI für eine SQL-User-Federation erfolgreich betrieben werden kann. Resultierend sollen dadurch Benutzer aus einer SQL-Datenbank produktiv gemanagt werden können.

Um eine Implementierung der User-Storage-SPI erfolgreich umzusetzen, muss eine UserStorageProvider-Klasse und eine UserStorageProviderFactory-Klasse definiert werden (Namensgebung ist nicht verpflichtend). Zur Laufzeit werden später automatisch Instanzen der UserStorageProvider-Klasse je Transaktion der UserStorageProviderFactory-Klasse erstellt. Die UserStorageProvider-Klasse übernimmt dabei alle Aufgaben, die für die Benutzersuche und Benutzeroperationen erforderlich sind [14].

UserStorageProvider:

public class UserStorageProvider implements
    UserLookupProvider, UserStorageProvider,
    CredentialInputValidator, CredentialInputUpdater,
    UserQueryProvider, UserRegistrationProvider {

  private final KeycloakSession ksession;
  private final ComponentModel model;
 
  // Enthält Funktionen um einen Nutzer aus einer SQL DB zu holen
  private final UserRepository userRepository;


  public UserStorageProvider(
      final KeycloakSession ksession,
      final ComponentModel model) {
    this.ksession = ksession;
    this.model = model;

    // z.b. hier eine Datenbank Verbindung aufbauen
    ... connection = ...
    userRepository = new UserRepository(connection);
  }
  ...
    
  @Override
  public boolean isValid(final RealmModel realm, final UserModel user, final CredentialInput credentialInput) {
    if (!supportsCredentialType(credentialInput.getType())) {
      return false;
    }

    final StorageId sid = new StorageId(user.getId());
    final String username = sid.getExternalId();
    final String password = credentialInput.getChallengeResponse();
    
    // Repository Pattern: Hat eine Verbindung zur DB,         
    // implementiert Funktionen um Nutzer aus der DB zu extrahieren  
    return userRepository.findUserByUsernameAndPassword(username, password);
  }

  @Override
  public UserModel getUserById(RealmModel realmModel, String id) {
    final StorageId sid = new StorageId(id);
    return new UserAdapter(ksession, realmModel, model, userRepository.findUserByUsername(sid.getExternalId()))
  }

  @Override
  public UserModel getUserByUsername(RealmModel realmModel, String username) {
    // User Entität
    final User user = userRepository.findUserByUsername(username);
    if (user != null) {
      // Gibt das Keycloak Basis User Model zurück
      return new UserAdapter(ksession, realmModel, model, user);
    }
      
    return null;
  }

  @Override
  public UserModel getUserByEmail(RealmModel realmModel, String email) {
    return getUserByUsername(realmModel, email);
  }
  ...
}

In der UserStorageProvider-Klasse wird hier zunächst eine Verbindung zu einer SQL-Datenbank genutzt (Konstruktor), in der die Benutzer gespeichert sind, die mit dem Provider gemanagt werden sollen. Die Nutzerbehandlung kann seitens des zu implementierenden Providers adäquat mit einer Nutzer-Entität und einem zugehörigen Repository-Pattern umgesetzt werden. Hier empfiehlt sich ein ORM wie beispielsweise Hibernate [15]. Gerade im Bezug auf Unit-Tests ist Hibernate erfahrungsgemäß leichter zu testen als beispielsweise JOOQ [16] und bietet mehr Code-Sicherheit als einfache SQL-Queries [17].

Im Code der UserStorageProvider-Klasse werden Nutzer-Credentials validiert und der zugehörige Inhaber eines Realms (entspricht einem Mandat) anhand seiner ID, seines Namens oder der Email-Adresse aus der SQL-Datenbank extrahiert und entsprechend dem Keycloak-User-Model zugeordnet und zurückgegeben. Um diese Prozesse anzustoßen, muss die UserStorageProviderFactroy-Klasse Instanzen der UserStorageProvider-Klasse zur Laufzeit erstellen können.

UserStorageProviderFactory:

public class UserStorageProviderFactory implements
    UserStorageProviderFactory<UserStorageProvider> {
    
  @Override
  public String getId() {
    return "SQL_PROVIDER";
  }

  @Override
  public UserStorageProvider create(final KeycloakSession ksession, final ComponentModel model) {
    return new UserStorageProvider(ksession, model);
  }
 
  /** Konfigurationsparameter die später über die Keycloak Admin GUI       
   * verwentet werden können.
   * Z.b. können hier auch DB Host, Name, Nutzername und Password als Parameter
   * gesetzt werden. Diese Parameter müssen dann für die Herstellung der
   * DB-Connection verwendet werden (z.b. public static final String HOST).
   * **/
  @Override
  public List<ProviderConfigProperty> getConfigProperties() {
    return ProviderConfigurationBuilder
        .create()
        .property(
            "parameter",
            "label",     
            "description",
            ProviderConfigProperty.STRING_TYPE,
            "value",
            null
            ).build();
  }
  ...  
}

Dafür wird in der UserStorageProviderFactory-Klasse die zuvor designte UserStorageProvider-Klasse als Template-Parameter implementiert. Zur Laufzeit wird die UserStorageProvider-Klasse introspektiert, um die Schnittstelle zum Nutzer in der SQL-Datenbank zu prüfen.

Zudem wird in der UserStorageProvider-Klasse ein UserAdapter (Namensgebung ist nicht verpflichtend) als Helper-Klasse verwendet (muss von AbstractUserAdapter erben). Die Klasse bietet eine Basisimplementierung für das oben bereits erwähnte UserModel in Keycloak. Dabei wird automatisch eine user id auf Grundlage der Definition einer sogenannten Keycloak-Storage-ID generiert. Dafür wird der Benutzername eines Nutzers als external id verwendet. Das Format für die user id wird dann wie folgt permutiert "f:" + component id + ":" + external id. Die user id wird von der Keycloak-Runtime häufig zur gezielten Suche nach Benutzern verwendet. Da die user id ausreichend Information enthält, muss Keycloak später nicht jeden einzelnen bereits erstellten UserStorageProvider abfragen, um den entsprechenden Nutzer zu finden. Die kontextuelle component id wird mit der Erstellung eines UserStorageProviders für einen Nutzer generiert und kann nachfolgend für die Suche von Keycloak intern verwendet werden [14].

UserAdapter:

public class UserAdapter extends AbstractUserAdapter {

  @Getter
  // User Entität
  private final User user;
  private final String username;

  public UserAdapter(final String username,
                     final KeycloakSession session,
                     final RealmModel realm,
                     final ComponentModel storageProviderModel,
                     final User user) {
    super(session, realm, storageProviderModel);
    this.username = username;
    this.user = user;
  }

  @Override
  public String getUsername() {
    return username;
  }
  ...
}

Unter Verwendung von mvn clean install kann das Projekt gebaut werden und ist dann als jar-Datei im erzeugten target-Project-Directory verfügbar. Die jar-Datei kann nun bei der Installation von Keycloak eingebunden werden. Sobald der benutzerdefinierte Benutzerspeicheranbieter in Form einer SQL-Datenbank in Keycloak registriert ist, kann er in der Keycloak-Administrationskonsole konfiguriert werden. Der SQL-Nutzerdatenspeicher sollte dann verwendet werden können, um Benutzerdaten während des Authentifizierungsprozesses abzurufen.

Abb. 3: Provider ist über die User-Federation verfügbar.

Abb. 4: ProviderConfigProperties können hier übergeben werden.

Bereitstellen eines Container-Images

Um die .jar-Datei aus dem Projekt target-Ordner für eine Installation in Kubernetes bereitstellen zu können, muss sie in ein Container-Image verpackt und in eine Registry (Docker-Hub, Gitlab, Github, ...) geladen werden. Hier wird exemplarisch Docker verwendet. Dazu wird zunächst ein minimales Dockerfile benötigt, das in etwa wie folgt aussehen könnte.

FROM maven:3.8-openjdk-17-slim
RUN mkdir /opt/app
COPY target/keycloak-spi-1.0-SNAPSHOT.jar /opt/app
CMD ["java", "-jar", "/opt/app/target/keycloak-user-storage-spi-1.0-SNAPSHOT.jar"]

Anschließend muss das Image, welches die .jar-Datei aus dem lokalen Projekt-target-Directory in ein Container-Verzeichnis kopiert, in eine Container-Registry geladen werden.

$ docker build -t keycloak-user-storage-spi . && docker tag keycloak-user-storage-spi <your-registry-tag>/keycloak-spi:1.0.0 && docker push <your-registry-tag>/keycloak-user-storage-spi:1.0.0

Das Container-Image ist nun in eine Registry hochgeladen und kann mit den entsprechenden Anmeldeinformationen (Projekt-Images sollten niemals public sein) geladen werden.

Installation in Kubernetes

Um Keycloak in Kubernetes zu installieren, benötigt man zunächst einen Kubernetes-Cluster. Man kann dazu ein beliebiges Environment benutzen, wie z. B. Minikube, K3, Kind, Hetzner, AWS oder GKE.

Es gibt verschiedene Möglichkeiten, Keycloak in Kubernetes zu installieren, z. B. über einen Keycloak-Operator [18] oder ein Helm-Chart. Es gibt derzeit kein offizielles Helm-Chart von Keycloak für die Installation in Kubernetes. Das Helm-Chart von Codecentric bietet deshalb eine gute Option als gepflegte und vertrauenswürdige Quelle [19].

Hinweis: Kubernetes-Operatoren sind eine Erweiterung von Kubernetes, die es Entwicklern ermöglicht, benutzerdefinierte Ressourcen und Logik für die Verwaltung von Anwendungen in Kubernetes-Clustern zu definieren. Ein Operator nutzt die Kubernetes-APIs, um benutzerdefinierte Ressourcen und Logik für die Verwaltung von Anwendungen bereitzustellen. Ein Operator besteht aus mehreren Komponenten, einschließlich eines benutzerdefinierten Controllers, der die spezifische Logik für die Verwaltung der Anwendung implementiert [20].

Es ist natürlich ebenfalls möglich, den Keycloak-Operator zu nutzen, dieser kann überdies auch über ein selbst implementiertes Helm-Chart verwaltet und somit auch einer Versionskontrolle unterzogen werden. Für diesen Beitrag bringt die erhöhte Komplexität eines Kubernetes-Operators keinen Mehrwert und es wird deshalb auf ein Helm-Chart von Codecentric zurückgegriffen.

Hinweis: Die nachfolgend beschriebene Basisinstallation von Keycloak muss für einen produktiven Einsatz erweitert werden. So enthält die Beschreibung neben anderen – für einen produktiven Einsatz erforderlichen – Erweiterungen beispielsweise keine Definition einer Ingress-Route oder eines Realm Imports.

Um eine möglichst aktuelle Version von Keycloak zu installieren, soll das Codecentric/Keycloakx-Helm-Chart verwendet werden [19]. Um das Container-Image bei der Installation von Keycloakx mit auszuliefern, muss die values.yaml aus dem Github-Repository von Codecentric wie folgt interpoliert werden.

# Secret das die Anmeldeinformationen zu der Registry enthält
# in der sich das Container Image befindet, welches die .jar-Datei enthält
imagePullSecrets:
  - name: docker-registry-secret

extraInitContainers: |
  - name: keycloak-user-storage-spi
    image: <your-registry-tag>/keycloak-user-storage-spi:1.0.0
    imagePullPolicy: Always
    command:
      - sh
    args:
      - -c
      - cp /opt/app/keycloak-user-storage-spi*.jar /extensions
    volumeMounts:
      - name: extensions
        mountPath: /extensions

extraVolumes: |
  - name: extensions
    emptyDir: {}

extraVolumeMounts: |
  - name: extensions
    mountPath: "/opt/keycloak/providers"

# An dieser Stelle können Features für Kubernetes enabled und disabled werden
# Um beispielsweise alle Features zu disablen könnte eine
# weitere command Sektion hinzu gefügt, oder eine Shell in
# dem laufenden Container gestartet werden.
# Z.b.: ./opt/keycloak/bin/kc.sh build --features-disabled=default um alle
# Features auszuschalten
command:
  - "/opt/keycloak/bin/kc.sh"
  - "start"
  - "--optimized"
  - "--http-enabled=true"
  - "--http-port=8080"
  - "--hostname-strict=false"
  - "--hostname-strict-https=false"

# Empfohlene Default Envs für die Installation
extraEnv: |
  - name: JAVA_OPTS_APPEND
    value: >-
      -Djgroups.dns.query={{ include "keycloak.fullname" . }}-headless
  - name: KEYCLOAK_LOGLEVEL
    value: DEBUG
  - name: KEYCLOAK_ADMIN
    value: admin
  - name: KEYCLOAK_ADMIN_PASSWORD
    value: admin_Pa$$w0rd

Das docker-registry-secret in der abgebildeten values.yaml ist ein Kubernetes Secret, das die Anmeldeinformationen zur Container-Registry beinhaltet und muss vor der Keycloak-Installation in Kubernetes im gleichen Namespace wie Keycloak angelegt werden [21]. Im nächsten Schritt lädt ein Init-Container das Container-Image von der Registry (in dem sich die User-Storage-SPI-jar-Datei befindet), das nachfolgend über ein ephemerales Volumen in den Keycloak-Container gemountet wird. Um die Installation für Keycloak auszuführen, ist dafür nur ein einfacher Helm-Befehl notwendig.

$ helm install keycloak codecentric/keycloakx -f values.yaml

Wenn alles geklappt hat, dann sollte Keycloakx als Basisinstallation in einem Kubernetes-Cluster als StatefulSet vorhanden und die User-Storage-SPI entsprechend konfigurierbar sein.

Zusammenfassung

Keycloak ist eine Open-Source-Software-Lösung, die als vorkonfigurierter Java Quarkus Standalone-Application-Server für Identity-Access-Management genutzt werden kann. Keycloak bietet eine große Auswahl an built-in-Features. Darüber hinaus können Service-Provider-Interfaces zur Erweiterung und Konfiguration von Funktionalität implementiert werden. Seit 2018 befindet sich Keycloak unter der Regie von RedHat, woraufhin der WildFly Application Server durch Quarkus abgelöst wurde. In jüngerer Zeit (2022/2023) hat die stetige Weiterentwicklung von Keycloak, Verbesserung von Funktionen und Performance mittleren bis großen Einfluss auf die Abwärtskompatibilität des Produkts. Für ein Upgrade muss an einigen Stellen nachkonfiguriert werden, da beispielsweise ein initialer realm.json-Import fehlschlagen wird. Auch im Bezug auf einige SPIs, wie z. B. der User-Storage-SPI muss für ein Upgrade auf Keycloak v19.0.0 manuell in der Codebase nachgebessert werden, um die bisherige Funktionalität zu adaptieren. Jedoch bietet Keycloak eine gut gepflegte und sehr umfangreiche Dokumentation inklusive einfacher Codebeispiele.

Im Zuge der Entwicklung kann es zu Schwachstellen kommen und auch hier ist Keycloak keine Ausnahme. Im Regelfall wird hier schnell und zuverlässig analysiert, repariert und ausgeliefert. Keycloak kann ohne weiteres in Kubernetes betrieben werden, bietet hier zwar kein offizielles Helm-Chart, dafür aber einen Kubernetes-Operator und auch hier eine umfassende Dokumentation als Hilfestellung für Installation, Features und Upgrade.

Für einfache Entwicklungs- und Testszenarien kann das inoffizielle Helm-Chart aus dem Hause Codecentric verwendet werden. Keycloak kann darüber hinaus als Bestandteil einer Zero-Trust-Architektur genutzt werden und bietet dort, wie auch abseits davon, eine gute Option für eine Nutzerverwaltung mit SSO.

Quellen