Comment sécuriser vos clusters Elasticsearch avec Kerberos

By
Yogesh Gaikwad
•
Josh Bressers

Cerbère, Kerberos en grec ancien – le chien à trois têtes gardant l'accès à vos données

Bonne nouvelle pour les abonnements Platinum : Elasticsearch 6.4 accepte désormais l'authentification Kerberos – un premier pas vers une Suite Elastic intégralement kerbérisée. Kerberos est une technologie mature qui permet l'authentification sécurisée dans les systèmes distribués. Avec Kerberos, vous accédez à différents services par authentification unique, sans devoir saisir vos nom d'utilisateur et mot de passe à chaque connexion. Cet article de blog explique comment configurer Elasticsearch afin qu'il accepte l'authentification Kerberos pour le trafic HTTP.

Vue d'ensemble du déploiement

Imaginons un scénario assez simple, où une utilisatrice que nous appellerons Alice dispose d'un cluster Elasticsearch à nœud unique. Alice a déjà un domaine Kerberos, demo.local, et elle voudrait sécuriser son cluster Elasticsearch au moyen de l'authentification Kerberos. Le serveur d'authentification Kerberos dispose de l'autorité nécessaire pour authentifier les utilisateurs, les hôtes, ou encore les services du domaine. Les commandes citées dans cet article se rapportent à l'implémentation Kerberos du MIT (Massachusetts Institute of Technology). Pour en savoir plus, n'hésitez pas à consulter la documentation MIT Kerberos.

Ce scénario simple comporte trois machines hôtes :

  • Host-1 (kdc.demo.local): Il s'agit du Centre de distribution de clés Kerberos (KDC), qui assure généralement des responsabilités de serveur d'authentification (AS) et de serveur d'émission de tickets (TGS).
  • Host-2 (es.demo.local): C'est là que réside le cluster Elasticsearch à nœud unique.
  • Host-3 (client.demo.local): C'est là que réside le client Elasticsearch.

SimpleESKerberosDeployment

Voici les étapes à suivre pour une authentification Kerberos réussie :-

  1. Alice (alice@DEMO.LOCAL) se connecte à la machine cliente (client.demo.local) grâce à ses informations d'identification.
  2. La machine cliente demande un ticket d'émission de tickets (TGT, Ticket-granting Ticket) au serveur KDC (kdc.demo.local)
  3. Le client accède au service Elasticsearch https://es.demo.local:9200, qui renvoie à son tour une réponse contenant un code d'état HTTP Unauthorized(401) et l'en-tête WWW-Authenticate: Negotiate.
  4. Le client demande au serveur d'émission de tickets (TGS) un ticket de session à attribuer au principal du service Elasticsearch HTTP/es.demo.local@DEMO.LOCAL. Le nom principal du service Elasticsearch est dérivé de l'URL utilisée pour accéder au service.
  5. Le client présente ce ticket au service Elasticsearch pour authentification.
  6. Le service Elasticsearch valide le ticket Kerberos et accorde l'accès (si le ticket est valide).

Configurons le domaine Kerberos

Pour activer le domaine Kerberos Elasticsearch, votre infrastructure Kerberos doit être en place :

- Les horloges de toutes les machines participantes du domaine doivent être synchronisées. - Un DNS opérationnel doit exister pour toutes les machines participantes. - Vous disposez d'un serveur KDC. - Vous avez installé les nœuds clients avec les bibliothèques Kerberos et disposez de fichiers de configuration tels que kinitet klist.

En partant du principe que votre infrastructure Kerberos est en place, vous aurez besoin des informations suivantes :

- **Fichier de configuration Kerberos ** krb5.conf – ce fichier contient des informations essentielles sur votre environnement Kerberos, tels que le domaine par défaut, les serveurs KDC et les mappages de domaines. Sur un système Linux, ce fichier se trouve généralement dans le répertoire /etc. La propriété système java.security.krb5.conf de la machine virtuelle Java (JVM) doit être définie sur le chemin d'accès complet de ce fichier de configuration. La machine virtuelle Java charge ensuite cette configuration et l'utilise pour rechercher les informations nécessaires en temps utile. - keytabdu service HTTP Elasticsearch – un keytab est un fichier où sont stockées des paires de noms principaux et de clés de chiffrement. Il s'agit du keytab qu'utilise le service HTTP Elasticsearch pour valider les tickets reçus des clients. En général, le ou les noms principaux du service suivent le format HTTP/es.demo.local@DEMO.LOCAL, où HTTP représente la classe de service, es.demo.local représente le nom de domaine complet de l'hôte Elasticsearch et DEMO.LOCAL représente le domaine Kerberos. Vous devez placer ce fichier dans le répertoire config Elasticsearch. Attention : ce fichier contient des informations d'identification. Assurez-vous de le protéger par un accès en lecture seule. Vous pouvez demander le keytab dont vous avez besoin pour votre service à l'administrateur système Kerberos.

Armé de ces deux fichiers, nous pouvons maintenant configurer le domaine Kerberos dans Elasticsearch.

1. Configurer les options JVM

Nous devons commencer par modifier le fichier d'options JVM (jvm.options). Cela nous permet de configurer la propriété système de la machine virtuelle Java (JVM) pour le fichier de configuration Kerberos :

# Kerberos configuration
-Djava.security.krb5.conf=/etc/krb5.conf

2. Configurer Elasticsearch pour Kerberos

Ensuite, nous devons ajouter un domaine Kerberos au fichier elasticsearch.yml :

# Kerberos realm
xpack.security.authc.realms.kerb1:
type: kerberos
    order: 1
    keytab.path: es.keytab

Cela nous permet de définir le domaine Kerberos (kerb1) sur le type kerberos et l'ordre du domaine sur 1, et de faire pointer keytab.path vers le fichier keytab du service Elasticsearch (es.keytab), qui se trouve dans le répertoire de configuration. Pour en savoir plus, consultez la documentation consacrée à la configuration des domaines Kerberos : Configuring a Kerberos realm.

3. Redémarrer Elasticsearch

Une fois la configuration terminée, vous devez redémarrer le nœud Elasticsearch.

4. Mapper les utilisateurs Kerberos à des rôles

Kerberos est un protocole d'authentification qui ne fournit pas d'autorisation détaillée. Pour l'autorisation, nous pouvons donc utiliser l'API de mappage de rôles, qui permet de mapper les utilisateurs à des rôles. Ci-dessous, nous créons un mappage de rôles nommé kerbrolemapping, où le rôle monitoring_user est attribué à l'utilisatrice alice@DEMO.LOCAL :

$ curl -u elastic -H "Content-Type: application/json" -XPOST http://es.demo.local:9200/_xpack/security/role_mapping/kerbrolemapping -d 

{
    "roles" : [ "monitoring_user" ],
    "enabled": true,
    "rules" : {
    "field" : { "username" : "alice@DEMO.LOCAL" }
    }
}

Pour en savoir plus sur le mappage de rôles, reportez vous à la documentation traitant du mappage des utilisateurs et des groupes à des rôles : Mapping users and groups to roles

Et voilà, ça fonctionne !

Pour vérifier le bon fonctionnement de l'authentification sur la machine cliente, nous devons envoyer la commande kinit afin d'obtenir un ticket d'émission de tickets (TGT, Ticket-granting Ticket) :

$ kinit alice@DEMO.LOCAL  
Password for alice@DEMO.LOCAL:  
$ klist  
Ticket cache: KEYRING:persistent:1000:krb_ccache_NvNtNgS  
Default principal: alice@DEMO.LOCAL  

Valid starting      Expires             Service principal
31/08/18 02:20:07   01/09/18 02:20:04   krbtgt/DEMO.LOCAL@DEMO.LOCAL

Nous invoquons ensuite curl avec le paramètre negotiate pour assurer l'authentification Kerberos sur HTTP :

$ curl --negotiate -u : -XGET http://es.demo.local:9200/

Et le tour est joué !

{
    "name" : "Lw7K29R",
    "cluster_name" : "elasticsearch",
    "cluster_uuid" : "qd3iafXORLy0VCfVD_Hp9w",
    "version" : {
    "number" : "6.4.0",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "595516e",
    "build_date" : "2018-08-17T23:18:47.308994Z",
    "build_snapshot" : true,
    "lucene_version" : "7.4.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
    },
    "tagline" : "You Know, for Search"
}

Conclusion

Comme nous venons de le voir, une fois que nous disposons du fichier de configuration Kerberos et du keytab associé au nom principal du service, la configuration d'un domaine Kerberos n'a rien de sorcier. Quelques lignes de configuration du domaine Kerberos pour Elasticsearch, et le tour est joué. La prise en charge de Kerberos dans Elasticsearch n'est qu'un début. Nous comptons bien continuer d'étendre cette prise en charge à d'autres composants de la Suite Elastic dans de prochaines mises à jour. Affaire à suivre…