Introduction :
La sécurité et la gestion centralisée des accès sont des enjeux majeurs pour les entreprises modernes. L’authentification unique (SSO) avec Keycloak est une solution puissante pour simplifier la gestion des identités et sécuriser l’accès aux applications, y compris les solutions de sécurité comme Wazuh.
Cependant, la plupart des guides disponibles pour intégrer le SSO avec Wazuh se concentrent sur des déploiements traditionnels sur serveurs nus. Avec l’essor des environnements conteneurisés et des orchestrateurs comme Kubernetes, il est essentiel de disposer d’un guide adapté à ces nouveaux paradigmes.
Dans cet article, nous vous proposons un tutoriel complet pour configurer l’authentification SSO sur Wazuh en utilisant Keycloak, dans un déploiement Kubernetes. Ce guide est conçu pour ceux qui utilisent des déploiements Dockerisés et souhaitent profiter de la flexibilité et de l’évolutivité qu’offre Kubernetes. Préparez-vous à simplifier votre gestion des accès tout en renforçant la sécurité de votre infrastructure.
Partie 1 : Configuration de Keycloak pour le SSO avec Wazuh
Étape 1 : Création du Royaume dans Keycloak
Un royaume dans Keycloak est un conteneur isolé pour gérer les identités, les utilisateurs, les clients, et les rôles. Pour débuter :
- Connectez-vous à la console d’administration Keycloak.
- Dans le menu principal, cliquez sur Add Realm.
- Donnez-lui un nom, par exemple Wazuh, et cliquez sur Créer.
Ce royaume servira de base pour centraliser les utilisateurs, les groupes, ainsi que les métadonnées IdP (Identity Provider) et SP (Service Provider) nécessaires à l’intégration. Il génèrera également les URL nécessaires pour connecter Keycloak et Wazuh.
Étape 2 : Création d’un Client SAML
Dans Keycloak, un client représente une application intégrée pour l’authentification. Pour Wazuh :
- Allez dans Clients > Créer un client.
- Configurez les paramètres suivants :
- Type de client : SAML.
- ID client :
wazuh-saml.
- Cliquez sur Enregistrer.
Ce client facilitera les échanges SAML entre Keycloak et Wazuh, permettant une authentification fluide
Étape 3 : Configuration du Client
Accédez à Clients > Settings et assurez-vous que le bouton Enabled est bien positionné sur ON. Complétez la section avec les paramètres suivants :
- Client ID:
wazuh-saml - Name:
Wazuh SSO - Valid redirect URIs:
https://<WAZUH_DASHBOARD_URL>/* - IDP-Initiated SSO URL name:
wazuh-dashboard - Name ID format:
username - Force POST binding:
ON - Include AuthnStatement:
ON - Sign documents:
ON - Sign assertions:
ON - Signature algorithm:
RSA_SHA256 - SAML signature key name:
KEY_ID - Canonicalization method:
EXCLUSIVE - Front channel logout:
ON
Remplacez le champ <WAZUH_DASHBOARD_URL> par l’URL correspondante de votre instance du tableau de bord Wazuh.
La configuration finale doit ressembler à l’exemple illustré dans les zones encadrées en bleu.
Vous pouvez laisser les autres valeurs par défaut. Cliquez sur Save pour appliquer la configuration.
Ensuite, accédez à Clients > Keys et configurez les paramètres suivants :
- Client signature required:
Off
Accédez à Clients > Advanced > Fine Grain SAML Endpoint Configuration et complétez la section avec les paramètres suivants :
- Assertion Consumer Service POST Binding URL: https://<WAZUH_DASHBOARD_URL>/_opendistro/_security/saml/acs/idpinitiated
- Logout Service Redirect Binding URL : https://<WAZUH_DASHBOARD_URL>
Remarque : Remplacez <WAZUH_DASHBOARD_URL> par l’URL correspondant à votre instance du tableau de bord Wazuh.
Vous pouvez laisser les autres valeurs par défaut. Cliquez sur Save pour appliquer la configuration.
Étape 4 : Création d’un Rôle
Les rôles définissent les permissions des utilisateurs ou des groupes. Pour Wazuh :
- Accédez à Realm roles > Create role.
- Nommez le rôle admin et cliquez sur Save.
Étape 5 : Création d’un Utilisateur
Pour tester et valider la configuration SSO :
- Allez dans Users > Add user.
- Remplissez les champs obligatoires (nom, email, etc.) et cliquez sur Create.
Accédez à Users > Credentials > Set password, puis saisissez un mot de passe pour l’utilisateur nouvellement créé. Ces identifiants seront utilisés pour se connecter au tableau de bord Wazuh.
Étape 6 : Création d’un Groupe et Attribution de l’Utilisateur
Les groupes simplifient la gestion des permissions :
Allez dans Groups > Create group et nommez-le Wazuh-admins.
Ajoutez l’utilisateur créé au groupe via Members > Add member.
Attribuez le rôle admin au groupe dans l’onglet Role Mapping > Assign role.
Étape 7 : Configuration d’un Mappeur de Protocoles
Les mappeurs convertissent les informations des utilisateurs en attributs SAML compatibles avec Wazuh
Accédez à Client scopes > role_list > Mappers > Configure a new mapper.
Sélectionnez Role list dans la liste comme indiqué ci-dessous :
Complétez la section Add mapper avec les paramètres suivants :
- Mapper type : Role list
- Name : wazuhRoleKey (vous pouvez utiliser n’importe quel nom)
- Role attribute name : Roles (cela correspondra à roles_key dans la configuration de l’indexeur Wazuh)
- SAML Attribute NameFormat : Basic
- Single Role Attribute : On
Cliquez sur Save pour appliquer la configuration.
Supprimez le mappeur par défaut role list pour éviter des erreurs 500.
Étape 8 : Récupération des Paramètres pour Wazuh
Les paramètres déjà obtenus lors de l’intégration sont :
- sp.entity_id : wazuh-saml
- roles_key : Roles
- kibana_url :
https://<WAZUH_DASHBOARD_URL>
Pour obtenir les paramètres restants :
- Accédez à Clients et sélectionnez le nom de votre client, dans notre cas wazuh-saml.
- Allez dans Action > Download adapter config, et assurez-vous que l’option Format est définie sur Mod Auth Mellon files.
- Cliquez sur Download pour télécharger les fichiers restants.
Les fichiers téléchargés contiennent les fichiers idp.metadata.xml et sp.metadata.xml.
- Le paramètre idp.entityID se trouve dans le fichier idp.metadata.xml.
- Le paramètre exchange_key est situé dans le champ ds:X509Certificate du fichier idp.metadata.xml.
Partie 2 : Configuration de l’indexeur wazuh
Configurer l’indexeur Wazuh dans un environnement Dockerisé demande des ajustements spécifiques, notamment en raison des contraintes liées aux pods Kubernetes. Dans cette partie, nous allons explorer comment préparer correctement l’indexeur Wazuh, en configurant les fichiers nécessaires, en créant une nouvelle image Docker et en adaptant le déploiement pour assurer une intégration transparente des modifications.
1. Placement des fichiers de configuration
La première étape consiste à positionner les fichiers idp.metadata.xml et sp.metadata.xml dans le répertoire suivant : /etc/wazuh-indexer/opensearch-security/
Une fois ces fichiers placés, il est nécessaire de modifier leurs permissions afin qu’ils soient associés à l’utilisateur et au groupe wazuh-indexer
Dans notre environnement Kubernetes, nous aurions pu utiliser des ConfigMap pour monter de manière persistante les fichiers. Cependant, nous rencontrons des limitations concernant la modification des permissions, car par défaut, l’utilisateur du pod Wazuh Indexer ne dispose pas de privilèges élevés. Pour contourner cette restriction, nous opterons pour la création d’une nouvelle image Docker contenant notre configuration. Les étapes suivantes détailleront ce processus pour résoudre ce problème.
2. Modification des fichiers de configuration
Comme mentionné précédemment , nous ne pouvons pas modifier directement les fichiers à l’intérieur des pods. Pour contourner cette limitation, nous allons récupérer et modifier les fichiers localement, puis recréer l’image de l’indexeur avec notre configuration personnalisée.
a) Récupération des fichiers depuis le pod
Nous devons récupérer les fichiers config.yml et role_mapping.yml depuis le pod pour les modifier sur notre machine locale.
b) Modification du fichier config.yml
Nous allons ensuite apporter les modifications recommander dans la documentation c’est à dire definir le order dans basic_internal_auth_domain sur 0 etdefinir le challenge drapeau sur false:
Inclure la configuration de saml_auth_domain sous la section authc:
c) Configuration du fichier role_mapping.yml
Configuration du fichier roles_mapping.yml pour mapper le rôle de domaine dans Keycloak au rôle d’indexeur Wazuh approprié ; dans notre cas, nous mappons cela au rôle all_access
d) Création de la nouvelle image Docker
Une fois vos fichiers modifiés, créez un répertoire où tous les fichiers nécessaires (idp.metadata.xml, sp.metadata.xml, config.yml, role_mapping.yml) sont rassemblés. Ensuite, créez un fichier Dockerfile avec le contenu suivant :
Dans ce fichier nous partons de l’image de base de wazuh-indexeur qui tourne sur notre cluster et nous appliquons toutes les modifications qui ne peuvent pas directement être effectuees dans le pod c’est à dire copier les idp.metadata.xml et sp.metadata.xml au bon emplacement copier les nouvelles versions des fichiers config.yml et role_mapping.yml (version modifier) dans leurs emplacements dans le pod. Ensuite en tant qu’utilisateur root nous definissons les proprietaires des fichiers et nous repassons ensuite à l’utilisateur wazuh-indexer qui est l’utilisateur par defaut de l’indexeur. Il est ensuite tant de construire notre image en executant la commande suivante :
3. Mise à jour du déploiement Kubernetes
Une fois l’image construite et poussée sur un registre (Docker Hub, par exemple), mettez à jour votre déploiement Kubernetes.
Entrez en mode édition :
Dans la section containers, remplacez l’image existante par votre nouvelle image :
4. Activation des changements avec le script securityadmin
Une fois les modifications apportées, quittez le fichier. Un nouveau pod sera créé à partir de notre nouvelle image, incluant toute notre configuration. Nous allons ensuite accéder au pod pour exécuter le script securityadmin afin d’appliquer les changements des fichiers role_mapping.yml et config.yml.
Pour ce faire, commencez par entrer dans le pod en utilisant la commande suivante :
Ensuite executons le script securityadmin:
Pour le fichier config.yml:
Pour le fichier role_mapping.yml :
Une fois ces scripts exécuter nous pouvons sortir du pod avec une simple commande exit.
Partie 3 : Configuration du dashboard wazuh
Comme précédemment nous ne pouvons pas appliquer directement les modifications dans le pod alors nous allons récupérer le fichier opensearch_dashboards.yml du pod :
C’est dans ce fichier que les modifications doivent être apporter. Et après modification notre fichier ressemble à ceci :
Nous allons ensuite reconstruire l’image de wazuh dashboard pour ce fait dans le repertoire où nous avons notre fichier opensearch_dashboards.yml on va creer un fichier Dockerfile qui doit se presenter comme suite :
Nous partons de l’image de base du wazuh-dashboard qui tourne actuellement dans le cluster nous copions la nouvelle version du fichier opensearch_dashboards.yml dans son emplacement dans le pod ensuite en tant qu’utilisateur root nous definissons le proprietaire du fichier et nous repassons ensuite en wazuh-dashboard user qui l’utilisateur par defaut de wazuh-dashboard.
Nous construisons ensuite l’image avec la commande :
Une fois notre image construite et pousser sur une registry nous allons modifier le déploiement de wazuh-dashboard afin qu’elle utilise la nouvelle image :
Une fois dans le fichier nous modifions l’image sous la section container :
Conclusion
En suivant ces étapes, vous avez mis en place une authentification SSO robuste et sécurisée entre Keycloak et Wazuh, adaptée à un environnement conteneurisé. Cette intégration améliore l’expérience utilisateur en centralisant la gestion des identités, tout en répondant aux exigences de sécurité modernes.
À retenir :
Dans un environnement conteneurisé, la création d’images personnalisées pour inclure les configurations spécifiques est une étape cruciale. Cela garantit une intégration fluide et évite les limitations liées aux permissions des pods.
La clé du succès réside dans une configuration minutieuse des paramètres SAML pour garantir une communication fluide entre les deux systèmes.
En cas de difficultés ou de questions, n’hésitez pas à consulter la documentation officielle de Keycloak et Wazuh. Vos retours sont précieux, alors partagez-les pour enrichir cette approche !
