🥇Lancement de Keycloak en mode HA sur Kubernetes

TL;DR: Ceci est une description de Keycloak, un système de contrôle d'accès open source, une analyse de son fonctionnement interne et des détails de configuration.

Introduction et concepts clés

Dans cet article, nous allons examiner les idées principales à garder à l'esprit lors du déploiement d'un cluster Keycloak sur Kubernetes.

Si vous souhaitez en savoir plus sur Keycloak, consultez les liens à la fin de l'article. Pour vous immerger davantage dans la pratique, vous pouvez étudier notre dépôt avec un module qui met en œuvre les concepts clés de cet article (un guide de démarrage est également disponible, cet article présentera un aperçu de la structure et des configurations, note du traducteur).

Keycloak est un système complexe écrit en Java et construit sur le serveur d'applications Wildfly. En bref, c'est un framework pour l'autorisation, offrant aux utilisateurs des applications la fédération et la possibilité de SSO (authentification unique).

Nous vous invitons à consulter la site ou Wikipedia pour une compréhension détaillée.

Démarrage de Keycloak

Keycloak nécessite deux sources de données persistantes pour fonctionner :

Une base de données utilisée pour stocker les données stables, telles que les informations sur les utilisateurs.
Un cache Datagrid, qui est utilisé pour mettre en cache les données de la base de données et pour stocker certaines métadonnées éphémères et souvent changeantes, telles que les sessions utilisateurs. Rélisé par Infinispan, qui est généralement beaucoup plus rapide qu'une base de données. Cependant, dans tous les cas, les données stockées dans Infinispan sont éphémères - elles ne doivent pas être sauvegardées lors du redémarrage du cluster.

Keycloak fonctionne en quatre modes différents :

Standard — un seul processus, configuré via le fichier standalone.xml
Cluster standard (version haute disponibilité) — tous les processus doivent utiliser la même configuration, qui doit être synchronisée manuellement. Les paramètres sont stockés dans le fichier standalone-ha.xml, un accès commun à la base de données et un répartiteur de charge doivent également être configurés.
Cluster de domaine — le lancement d'un cluster en mode standard devient rapidement une tâche routinière et ennuyeuse à mesure que le cluster se développe, car à chaque modification de la configuration, il faut apporter ces modifications sur chaque nœud du cluster. Le mode domaine résout ce problème en configurant un espace de stockage commun et en publiant la configuration. Ces paramètres sont stockés dans le fichier domain.xml
Réplication entre centres de données — si vous souhaitez exécuter Keycloak dans un cluster composé de plusieurs centres de données, souvent situés à des endroits géographiquement éloignés. Dans cette configuration, chaque centre de données disposera de son propre cluster de serveurs Keycloak.

Dans cet article, nous allons examiner en détail la deuxième option, à savoir un cluster standard, et nous aborderons également brièvement le sujet de la réplication entre les centres de données, car ces deux options ont du sens à exécuter dans Kubernetes. Heureusement, Kubernetes n'a pas de problèmes de synchronisation des paramètres de plusieurs pods (nodes Keycloak), donc un cluster de domaine ne sera pas trop difficile à mettre en place.

Veuillez également noter que le terme un cluster sera utilisé dans cet article uniquement en référence à un groupe de nodes Keycloak fonctionnant ensemble, sans qu'il soit nécessaire de faire référence au cluster Kubernetes.

Cluster standard de Keycloak

Pour exécuter Keycloak en mode standard, il est nécessaire de :

configurer une base de données externe partagée
installer un répartiteur de charge
avoir un réseau interne prenant en charge le multicast IP

Nous ne discuterons pas de la configuration de la base de données externe, car ce n'est pas l'objectif de cet article. Supposons donc qu'il existe quelque part une base de données fonctionnelle à laquelle nous avons un point de connexion. Nous allons simplement ajouter ces données dans les variables d'environnement.

Pour mieux comprendre comment Keycloak fonctionne dans un cluster à haute disponibilité (HA), il est essentiel de savoir à quel point cela dépend des capacités de clusterisation de Wildfly.

Wildfly utilise plusieurs sous-systèmes, certains d'entre eux étant utilisés comme répartiteurs de charge, d'autres pour la haute disponibilité. Le répartiteur de charge assure la disponibilité de l'application en cas de surcharge d'un nœud du cluster, tandis que la haute disponibilité garantit l'accès à l'application même en cas de défaillance d'une partie des nœuds du cluster. Parmi ces sous-systèmes, on trouve :

mod_cluster: fonctionne en collaboration avec Apache comme répartiteur de charge HTTP, dépend de TCP multicast pour la découverte des nœuds par défaut. Peut être remplacé par un répartiteur de charge externe.
infinispan: cache distribué utilisant les canaux JGroups comme couche de transport. Peut également utiliser le protocole HotRod pour communiquer avec un cluster externe Infinispan afin de synchroniser le contenu du cache.
jgroups: fournit une prise en charge de la communication de groupe pour des services hautement disponibles basés sur des canaux JGroups. Les canaux nommés permettent aux instances d'application dans le cluster de se connecter en groupes, de sorte que la communication possède des propriétés telles que la fiabilité, l'ordre et la sensibilité aux pannes.

Équilibreur de charge

Lors de l'installation d'un équilibreur de charge en tant que contrôleur d'entrée dans un cluster Kubernetes, il est important de prendre en compte les éléments suivants :

Le fonctionnement de Keycloak implique que l'adresse distante du client se connectant par HTTP au serveur d'authentification soit la véritable adresse IP de l'ordinateur client. Les paramètres de l'équilibreur de charge et de l'entrée doivent correctement établir les en-têtes HTTP X-Forwarded-For et X-Forwarded-Proto, ainsi que de conserver l'en-tête original HÔTE. La dernière version ingress-nginx (> 0.22.0) désactive cela par défaut

L'activation du drapeau proxy-address-forwarding en définissant la variable d'environnement PROXY_ADDRESS_FORWARDING dans true donne à Keycloak la compréhension qu'il fonctionne derrière un proxy.

Il faut également activer les sessions persistantes dans l'entrée. Keycloak utilise un cache distribué Infinispan pour conserver les données liées à la session d'authentification actuelle et à la session utilisateur. Les caches fonctionnent avec un seul propriétaire par défaut, en d'autres termes, cette session particulière est conservée sur un certain nœud du cluster, et d'autres nœuds doivent y accéder à distance s'ils ont besoin d'accéder à cette session.

En particulier, chez nous, contrairement à la documentation, l'attachement de session avec le nom de cookie AUTH_SESSION_ID. Keycloak a provoqué une boucle de redirection, donc nous recommandons de choisir un autre nom de cookie pour la session persistante.

De plus, Keycloak attache le nom du nœud ayant répondu en premier à AUTH_SESSION_ID, et comme chaque nœud dans une configuration hautement disponible utilise la même base de données, chacun d'eux doit avoir un identifiant de nœud distinct et unique pour gérer les transactions. Il est recommandé de définir dans JAVA_OPTS les paramètres jboss.node.name et jboss.tx.node.id comme uniques pour chaque nœud — par exemple, on peut utiliser le nom du pod. Si vous utilisez le nom du pod, n'oubliez pas la limite de 23 caractères pour les variables jboss, donc il est préférable d'utiliser un StatefulSet plutôt qu'un Deployment.

Un autre piège — si le pod est supprimé ou redémarré, son cache est perdu. Étant donné cela, il convient de définir le nombre de propriétaires de cache pour tous les caches à au moins deux, afin qu'une copie du cache reste. La solution consiste à déployer script pour Wildfly lors du lancement du pod, en le plaçant dans le répertoire /opt/jboss/startup-scripts dans le conteneur :

Contenu du script

embed-server --server-config=standalone-ha.xml --std-out=echo
batch

echo * Définir CACHE_OWNERS sur "${env.CACHE_OWNERS}" dans tous les cache-containers

/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})

run-batch
stop-embedded-server

après quoi définir la valeur de la variable d'environnement CACHE_OWNERS au besoin.

Réseau privé avec prise en charge de l'ip multicast

Si vous utilisez Weavenet comme CNI, le multicast fonctionnera immédiatement — et vos nœuds Keycloak pourront se voir dès leur démarrage.

Si vous n'avez pas de prise en charge de l'ip multicast dans le cluster Kubernetes, vous pouvez configurer JGroups pour fonctionner avec d'autres protocoles de découverte de nœuds.

La première option est d'utiliser KUBE_DNS, qui utilise un service sans tête pour découvrir les nœuds Keycloak, vous passez simplement à JGroups le nom du service qui sera utilisé pour la découverte des nœuds.

Une autre option est d'appliquer la méthode KUBE_PING, qui fonctionne avec l'API pour découvrir les nœuds (vous devez configurer serviceAccount avec les droits list et obtenir, puis configurer les pods pour utiliser cette serviceAccount).

Le moyen de découvrir des nœuds pour JGroups est configuré en définissant des variables d'environnement JGROUPS_DISCOVERY_PROTOCOL et JGROUPS_DISCOVERY_PROPERTIES. Pour KUBE_PING vous devez choisir les pods en spécifiant namespace et labels.

️ Si vous utilisez multicast et que vous lancez deux clusters Keycloak ou plus dans le même cluster Kubernetes (par exemple, l'un dans le namespace production, l'autre — staging) — les nœuds d'un cluster Keycloak peuvent rejoindre un autre cluster. Assurez-vous d'utiliser une adresse multicast unique pour chaque cluster en définissant les variablesjboss.default.multicast.address et jboss.modcluster.multicast.address dans JAVA_OPTS.

Réplication entre centres de données

Connexion

Keycloak utilise plusieurs clusters de caches Infinispan séparés pour chaque centre de données, où se trouvent les clusters Keycloak, composés de nœuds Keycloak. Mais il n'y a pas de différence entre les nœuds Keycloak dans différents centres de données.

Les nœuds Keycloak utilisent une grille de données Java externe (serveurs Infinispan) pour la communication entre les centres de données. La communication se fait via le protocole Infinispan HotRod.

Les caches Infinispan doivent être configurés avec l'attribut remoteStore, afin que les données puissent être stockées dans des caches distants (dans un autre centre de données, note du traducteur) . Il existe des clusters Infinispan distincts parmi les serveurs JDG, donc les données stockées sur JDG1 sur le site site1 seront répliquées sur JDG2 sur le site site2.

Enfin, le serveur JDG récipiendaire informe les serveurs Keycloak de son cluster via des connexions client, ce qui est une caractéristique du protocole HotRod. Les nœuds Keycloak sur site2 mettent à jour leurs caches Infinispan, et une session utilisateur spécifique devient également accessible sur les nœuds Keycloak sur site2.

Pour certains caches, il est également possible de ne pas faire de sauvegardes et de renoncer complètement à l'écriture de données via le serveur Infinispan. Pour cela, il faut retirer la configuration remote-store pour le cache Infinispan spécifique (dans le fichier standalone-ha.xml), après quoi un certain replicated-cache cessera également d'être nécessaire du côté du serveur Infinispan.

Configuration des caches

Il existe deux types de caches dans Keycloak :

Local. Il est situé à proximité de la base de données, sert à réduire la charge sur la base de données et à diminuer la latence de réponse. Dans ce type de cache, on stocke le realm, les clients, les rôles et les métadonnées utilisateur. Ce type de cache n'est pas répliqué, même si ce cache fait partie d'un cluster Keycloak. Si une entrée dans le cache change, un message de changement est envoyé aux autres serveurs du cluster, après quoi l'entrée est exclue du cache. Voir la description work ci-après, pour une description plus détaillée de la procédure.
Répliqué. Gère les sessions utilisateur, les tokens offline, et surveille également les erreurs de connexion pour détecter les tentatives de phishing de mots de passe et d'autres attaques. Les données stockées dans ces caches sont temporaires, ne sont stockées qu'en mémoire vive, mais peuvent être répliquées à travers le cluster.

Caches Infinispan

Sessions — un concept dans Keycloak, des caches distinctsappelés authenticationSessions, sont utilisés pour stocker les données des utilisateurs spécifiques. Les requêtes provenant de ces caches sont généralement nécessaires pour les navigateurs et les serveurs Keycloak, pas pour les applications. C'est ici qu'apparaît la dépendance aux sessions persistantes, et de tels caches n'ont pas besoin d'être répliqués, même en mode Active-Active.

Token d'action. Une nouvelle conception, généralement utilisée pour divers scénarios, lorsque, par exemple, un utilisateur doit faire quelque chose de manière asynchrone par email. Par exemple, pendant la procédure oubli de mot de passe cache actionTokens est utilisé pour suivre les métadonnées des tokens associés — par exemple, un token déjà utilisé, et qui ne peut pas être activé à nouveau. Ce type de cache doit généralement être répliqué entre les centres de données.

Mise en cache et expiration des données stockées fonctionne pour alléger la charge sur la base de données. Ce type de mise en cache améliore les performances, mais présente un problème évident. Si un serveur Keycloak met à jour des données, les autres serveurs doivent être informés de cela, afin qu'ils puissent mettre à jour les données dans leurs caches. Keycloak utilise des caches locaux realms, users et autorisation pour mettre en cache les données de la base.

Il existe également un cache distinct work, qui est répliqué dans tous les centres de données. Celui-ci ne stocke aucune donnée de la base, mais sert à envoyer des messages sur l'expiration des données aux nœuds du cluster entre les centres de données. En d'autres termes, dès que les données sont mises à jour, un nœud Keycloak envoie un message aux autres nœuds dans son centre de données, ainsi qu'aux nœuds d'autres centres de données. Après avoir reçu un tel message, chaque nœud procède à un nettoyage des données correspondantes dans ses caches locaux.

Sessions utilisateur. Les caches avec les noms sessions, clientSessions, offlineSessions et offlineClientSessions, sont généralement répliqués entre les centres de données et servent à stocker des données sur les sessions utilisateur, qui sont actives pendant l'activité de l'utilisateur dans le navigateur. Ces caches fonctionnent avec l'application traitant les requêtes HTTP des utilisateurs finaux, de sorte qu'elles sont liées aux sessions persistantes et doivent être répliquées entre les centres de données.

Protection contre les attaques par force brute. Le cache loginFailures sert à suivre les données des échecs de connexion, par exemple, le nombre de fois qu'un utilisateur a entré un mot de passe incorrect. La réplication de ce cache est une affaire d'administrateur. Mais pour un comptage précis, il est conseillé d'activer la réplication entre les centres de données. En revanche, si ces données ne sont pas répliquées, cela peut améliorer les performances, et si la question se pose — la réplication peut être désactivée.

Lors du déploiement du cluster Infinispan, il est nécessaire d'ajouter des définitions de caches dans le fichier de configuration :

Il est nécessaire de configurer et de démarrer le cluster Infinispan avant de lancer le cluster Keycloak

Ensuite, il faut configurer remoteStore pour les caches Keycloak. Pour cela, un script suffira, qui se fait de manière similaire à celui utilisé pour configurer la variable CACHE_OWNERS, il faut le sauvegarder dans un fichier et le placer dans le répertoire /opt/jboss/startup-scripts:

Contenu du script

embed-server --server-config=standalone-ha.xml --std-out=echo
batch

echo *** Mise à jour du sous-système infinispan ***
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module, value=org.keycloak.keycloak-model-infinispan)

echo ** Ajout de la liaison de socket distante au serveur infinispan **
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-cache:add(host=${remote.cache.host:localhost}, port=${remote.cache.port:11222})

echo ** Mise à jour de l'élément de travail cache répliqué **
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=work, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)

/subsystem=infinispan/cache-container=keycloak/replicated-cache=work:write-attribute(name=statistics-enabled,value=true)

echo ** Mise à jour de l'élément des sessions cache distribuées **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=sessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=statistics-enabled,value=true)

echo ** Mise à jour de l'élément offlineSessions cache distribuée **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=offlineSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Mise à jour de l'élément clientSessions cache distribuée **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=clientSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Mise à jour de l'élément offlineClientSessions cache distribuée **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=offlineClientSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Mise à jour de l'élément loginFailures cache distribuée **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=loginFailures, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=statistics-enabled,value=true)

echo ** Mise à jour de l'élément actionTokens cache distribuée **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    cache=actionTokens, 
    remote-servers=["remote-cache"], 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=statistics-enabled,value=true)

echo ** Mise à jour de l'élément authenticationSessions cache distribuée **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=statistics-enabled,value=true)

echo *** Mise à jour du sous-système undertow ***
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)

run-batch
stop-embedded-server

N'oubliez pas de configurer JAVA_OPTS pour les nœuds Keycloak afin de faire fonctionner HotRod : remote.cache.host, remote.cache.port et le nom du service jboss.site.name.

Liens et documentation supplémentaire

L'article a été traduit et préparé pour Habr par ses employés du centre de formation Slyorm — intensifs, cours vidéo et formation en entreprise dispensés par des professionnels (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Source : habr.com

Démarrage de Keycloak en mode HA sur Kubernetes