Role-based access control and external authentication is GA in ECE 2.3 | Elastic Blog
Technique

ECE 2.3 : le contrôle d'accès basé sur les rôles et l’authentification externe sont désormais disponibles !

Bonne nouvelle ! Avec la sortie d’Elastic Cloud Enterprise (ECE) 2.3, le contrôle d'accès basé sur les rôles et l’authentification avec des sources externes sont désormais disponibles. Grâce à ces fonctionnalités, vous pouvez contrôler l’accès de vos utilisateurs à la plateforme ECE en fonction de leur rôle. Vous pouvez ajouter des utilisateurs natifs dans ECE et connecter vos propres serveurs de répertoire ou fournisseurs d’identité pour concéder un accès à vos utilisateurs existants.

Nous avions initialement ajouté un support bêta pour ces fonctionnalités dans ECE 2.2. Outre la correction des bugs dans la version 2.3, nous avons ajouté un support pour Active Directory, en plus des options LDAP et SAML existantes.

Comment ça fonctionne ?

Lorsque l’on active RBAC pour ECE, on ajoute un déploiement de sécurité, c’est-à-dire un déploiement système qui gère l’ensemble de la configuration d’authentification et les autorisations. Lorsqu’un utilisateur essaye de se connecter, ECE vérifie l’authentification à l’aide du déploiement de sécurité, et se replie sur les utilisateurs système si nécessaire. Si l’utilisateur réussit à s’authentifier, ECE applique les rôles qui lui sont attribués et les convertit en autorisations détaillées qui contrôlent les données que cet utilisateur peut consulter et les actions qu’il peut effectuer.

Remarque : Les rôles ECE d’un utilisateur ne sont pas associés aux mêmes informations d’identification que celles que détient l’utilisateur pour les déploiements hébergés dans ECE. Un utilisateur peut ne pas avoir d’accès à ECE, et avoir cependant un accès administratif aux déploiements hébergés, et inversement.

Quels sont les rôles disponibles ?

ECE propose un vaste ensemble d’opérations, tant au niveau de la plateforme que du déploiement. Pour que les administrateurs ne perdent pas du temps à définir et à gérer leurs propres définitions de rôle, ECE fournit un ensemble de rôles prédéfinis couvrant la majorité des cas d'utilisation courants. Ces rôles seront maintenus à jour avec l’ajout de fonctionnalités. Vous n’avez donc aucun souci à vous faire de ce côté-là !

Les rôles sont décrits ci-dessous. Un utilisateur peut détenir plusieurs rôles et les combiner selon ses besoins. Par exemple, un administrateur de plateforme peut réaliser n’importe quelle action. Il n’est donc pas nécessaire de lui attribuer un autre rôle. Par contre, un visionneur de plateforme peut tout voir, mais ne peut rien changer. Pour y remédier, vous pouvez lui attribuer en plus un rôle de gestionnaire des déploiements.

Administrateur de plateforme

L’utilisateur qui dispose de ce rôle peut accéder à toutes les données et réaliser n’importe quelle opération dans ECE, à l’instar d’un utilisateur système admin (ou root dans ECE 1.x) créé lors du processus d’installation. Ce rôle sera en général détenu uniquement par les administrateurs en charge de la plateforme ECE intégrale. La section “Platform” (Plateforme) dans l’interface utilisateur est un bon exemple car elle donne différentes informations. Elle indique par exemple qui sont les allocators et quels sont leurs déploiements. Elle permet également de libérer un allocator ou de le placer en mode maintenance.

Visionneur de plateforme

Ce rôle octroie des autorisations de lecture seule pour l’intégralité de la plateforme et les déploiements hébergés. Les autorisations associées sont les mêmes que celles détenues par un utilisateur système readonly. C’est un rôle utile dans le cadre de l’automatisation, par exemple pour monitorer le statut d’ECE.

Gestionnaire des déploiements

L’utilisateur qui détient ce rôle peut créer et gérer des déploiements sur la plateforme. Il peut réaliser toutes les actions sur un déploiement : augmentation ou réduction de capacité, configuration d’instantanés, redémarrage de nœuds, réinitialisation de mots de passe et bien plus encore. En revanche, il ne peut pas accéder à des opérations ou ressources au niveau de la plateforme, comme les modèles de déploiement, les configurations d'instances, les allocators, les déploiements système, etc.

Ce rôle convient à un utilisateur ayant pour responsabilité de gérer les déploiements, sans avoir besoin d’accéder aux informations au niveau de la plateforme, comme les chefs d’équipe de développement.

Visionneur de déploiements

Un utilisateur qui dispose de ce rôle peut voir les déploiements, mais ne peut pas les modifier. C’est un rôle qui convient au personnel de support technique ou aux membres d’une équipe de développement.

Gestion des utilisateurs natifs

Pour vous familiariser avec les capacités RBAC, le plus simple pour commencer est de créer des utilisateurs natifs. Ceux-ci appartiennent au déploiement de sécurité, dans le domaine natif Elasticsearch. Ils ne prennent en charge qu’un nombre restreint d’attributs : nom d'utilisateur, nom complet, e-mail, mot de passe, rôles, et s’ils sont activés ou non.

Dans le menu de navigation, cliquez sur "Users" (Utilisateurs) pour afficher vos fournisseurs d’authentification. L’un d’eux est le profil "Native users" (Utilisateurs natifs). Ouvrez le profil : vous accéderez alors à une liste de tous les utilisateurs natifs. La liste inclut deux utilisateurs système créés par le programme d’installation d’ECE. Il n’est pas possible de modifier ou de supprimer ces utilisateurs. Vous ne pouvez pas non plus réinitialiser leurs mots de passe ici (consultez la documentation pour en savoir plus sur la réinitialisation des mots de passe).

Exemple de création d’utilisateurs natifs

Dans la page "Native users" (Utilisateurs natifs), vous pouvez créer, modifier et supprimer des utilisateurs natifs. Ces utilisateurs peuvent se connecter à ECE, tout comme les utilisateurs système. Leur accès est contrôlé par les rôles que vous leur attribuez.

Page des paramètres utilisateur

Dans la version 2.3, ECE dispose désormais d’une page relative aux paramètres utilisateur. Cliquez sur l’icône utilisateur en haut à droite de la page, et cliquez sur "Settings" (Paramètres). Si vous êtes connecté en tant qu’utilisateur natif, vous pouvez modifier votre nom et votre e-mail, ou changer de mot de passe. Si vous êtes connecté en tant qu’utilisateur avec un fournisseur d’authentification externe, vous accéderez à une page en lecture seule contenant quelques informations de base, le nom et le type de profil d’authentification, et les rôles que vous détenez.

Exemple de modification des paramètres utilisateur

Fournisseurs d’authentification externe

Si vous avez déjà un serveur LDAP, Active Directory ou SAML, vous pouvez configurer ECE de sorte à utiliser ce serveur dans le cadre de l’authentification et des autorisations. Vous pouvez même configurer plusieurs serveurs. Les tentatives d’authentification seront effectuées dans l’ordre que vous avez défini, comme pour Elasticsearch. Lorsque vous utilisez vos sources d’authentification existantes, vous devez gérer les utilisateurs dans un seul emplacement centralisé. La configuration de mapping des rôles pour un fournisseur externe vous permet de mapper les attributs des utilisateurs aux rôles dans ECE. Ainsi, les éventuels changements apportés aux attributs, comme l’appartenance à un groupe, sont automatiquement récupérés par ECE.

Sur la page d’aperçu des fournisseurs d’authentification, cliquez sur "Add provider" (Ajouter un fournisseur) et sélectionnez un type. C’est sur la page suivante que vous configurerez ensuite le fournisseur. Étudions les différentes options de configuration qui s’offrent à nous dans le cadre d’une configuration LDAP de base.

Exemple de création d’un fournisseur LDAP

Fournisseur d’authentification LDAP

Paramètres généraux :

  1. Chaque profil a un nom. Ce nom ne sert pas seulement à identifier le profil : il permet également de générer un ID de domaine. Remarque : Une fois le profil créé, il n’est pas possible de changer l’ID de domaine.
  2. Il est nécessaire de définir au moins un serveur LDAP, incluant le protocole ldap: ou ldaps: au démarrage. Si vous optez pour une stratégie d’équilibrage des charges basée sur DNS, vous ne pouvez définir qu’un seul serveur.
  3. Choisissez une stratégie d’équilibrage des charges en gardant la restriction indiquée ci-dessus à l’esprit.

Certificats de confiance :

  1. Si la sécurisation de votre serveur LDAP implique que les clients détiennent des certificats SSL/TLS spécifiques, vous devez préparer un fichier groupé et le mettre à disposition sur ECE via une URL. Pour en savoir plus, consultez la documentation.
  2. Si votre fichier groupé est protégé par mot de passe, indiquez le mot de passe ici.

Informations d’identification liées :

  1. Si des informations d’identification doivent être liées au serveur LDAP, vous pouvez les définir ici.
  2. Dans le cas contraire, cliquez sur la touche bascule “Bind anonymously” (Lier de façon anonyme).

Paramètres de mode de recherche :

  1. Vous pouvez indiquer les détails nécessaires dans le cadre d’une recherche utilisateur. Pour en savoir plus sur ces champs, consultez la documentation. Vous souhaiterez peut-être définir au moins le nom unique de base pour les utilisateurs, p. ex. “cn=users,dc=example,dc=com”.
  2. Autre possibilité : si vous avez plutôt besoin d’utiliser un modèle pour exécuter des requêtes LDAP, cliquez sur le bouton radio “Template” (Modèle) et fournissez un ou plusieurs modèles.

Paramètres de recherche de groupe :

  1. Comme pour les paramètres de mode de recherche, vous pouvez configurer la façon dont ECE doit rechercher les groupes d’un utilisateur. Vous souhaiterez peut-être définir le nom unique de base pour les groupes, p. ex. “ou=groups,dc=example,dc=com”.

Mappings de rôle :

  1. Un utilisateur doit détenir un ou plusieurs rôles pour pouvoir effectuer des actions dans ECE. Vous pouvez définir des rôles par défaut, qui seront attribués à tous les utilisateurs réussissant à s’authentifier. Par exemple, vous pourriez concéder à tous les utilisateurs le rôle “Visionneur de déploiements“, ce qui leur permettrait de voir l’ensemble des déploiements hébergés dans ECE, sans pour autant être autorisés à les modifier.
  2. L’autre méthode qui permet d’attribuer des rôles est le mapping de rôles. Concrètement, de quoi s’agit-il ? Ce sont des règles simples qui indiquent que si le nom unique de l’utilisateur ou du groupe correspond à une valeur précise, alors le ou les rôles associés à cette valeur lui sont attribués. Vous pouvez définir autant de mappings que vous le souhaitez. Vous pouvez par exemple mettre en place un mapping qui attribue aux utilisateurs des opérations informatiques un rôle “Visionneur de déploiements“, un deuxième qui concède aux développeurs le rôle de “Gestionnaire des déploiements“, ainsi qu’un troisième qui donne le rôle “Visionneur de plateforme“ à tous les administrateurs.

Lorsque vous avez terminé, cliquez sur Create profile (Créer le profil), et ECE reconfigure le déploiement de sécurité. À présent, il est temps de tester si vos mappings fonctionnent. Connectez-vous avec différents utilisateurs LDAP pour vérifier que l’authentification se fait bien et que les rôles attribués sont appropriés. Vous pouvez vérifier directement les rôles sur la page relative aux paramètres utilisateur, ou vous pouvez naviguer sur l’interface utilisateur et vérifier que les éléments auxquels les utilisateurs ont accès et ceux sur lesquels ils peuvent intervenir sont ceux que vous aviez prévus.

Fournisseurs d’authentification Active Directory et SAML

D’un point de vue général, le processus à suivre est similaire à celui appliqué pour LDAP. Vous créez un fournisseur d’authentification SAML ou Active Directory, vous lui donnez un nom, vous précisez la façon dont ECE doit communiquer avec le serveur, et vous définissez les mappings à appliquer.

Consultez la documentation pour en savoir plus sur la configuration d’un fournisseur d’authentification SAML ou d’un fournisseur d’authentification Active Directory.

Support technique API REST

Toutes les opérations décrites ci-dessus peuvent être également réalisées à l’aide de l’API REST. Par exemple, pour extraire une liste de tous les utilisateurs, même ceux actuellement désactivés :

GET /api/v1/users?include_disabled=true

Supposons que vous deviez créer un accès pour une nouvelle administratrice système, appelée Sarah. Vous pouvez créer un nouvel utilisateur natif pour elle, comme suit :

POST /api/v1/users
{
  "user_name": "sarah",
  "security": {
    "roles": ["ece_platform_admin"],
    "password": "deadb33f"
  }
}

Si, par la suite, vous souhaitez modifier l’accès de Sarah, vous pouvez envoyer une requête PATCH avec le champ concerné par la modification. Dans le cas présent, il s’agit des rôles :

PATCH /api/v1/users/sarah
{
  "security": {
    "roles": ["ece_platform_viewer"]
  }
}

Enfin, vous pouvez supprimer le compte de Sarah en envoyant une requête DELETE :

DELETE /api/v1/users/sarah

Pour en savoir plus sur les points de terminaison des fournisseurs d’authentification et obtenir des exemples, consultez la documentation sur l’API REST.

Lancez-vous aujourd’hui

Pour obtenir une liste complète des nouveautés de la version 2.3 d’ECE, consultez les notes de publication, et si vous voulez tester par vous-même, lancez-vous aujourd’hui avec une version d’essai gratuite de 30 jours.