Exécuter des plugins de type site avec Elasticsearch 5.0

By
Clinton Gormley

Il y a longtemps, dans la version 0.17, Elasticsearch a acquis la capacité à servir des pages Web statiques : les plugins de type site étaient nés. Ces plugins autorisaient les utilisateurs à créer des applications JavaScript fournissant des interfaces graphiques à Elasticsearch.

Les utilisateurs d'Elasticsearch ont alors développé sans relâche des plugins pour surveiller les statistiques d'Elasticsearch, pour gérer les index, pour la visualisation de la fusion de segments, pour le débogage de l'analyseur, pour la mise en cluster, et plus encore.

Aujourd'hui, les deux plugins les plus populaires sont Head et Kopf qui allient tous deux monitoring et gestion des index.

Jusque-là tout va bien. Et maintenant, voici les mauvaises nouvelles…

Les plugins de type site ne sont pas pris en charge dans Elasticsearch 5.0

Pourquoi supprimons-nous d'Elasticsearch cette fonctionnalité très appréciée ?

Elasticsearch n'est pas conçu comme un serveur Web. La faculté de servir des fichiers statiques était seulement due à un hack facile à installer sur l'interface HTTP REST fournie par Elasticsearch. Quel mal y a-t-il à servir des fichiers statiques ?

Il se trouve simplement que servir des fichiers statiques peut s'avérer dangereux. Parmi toutes les vulnérabilités découvertes dans Elasticsearch en matière de sécurité, deux sur sept étaient liées à des plugins. C'est énorme, surtout concernant une fonctionnalité accessoire. En revanche, deux des autres vulnérabilités étaient dues à des scripts dynamiques, si bien que nous avons créé un tout nouveau language de script pour résoudre ce problème !

Elasticsearch fonctionne désormais sous le Security Manager de Java. Nous avons verrouillé les permissions que la version de base requiert pour s'exécuter avec la configuration minimale. Nous faisons migrer cette fonctionnalité de l'application de base vers des modules, afin de restreindre l'escalade de permissions et l'accès aux fichiers au plus petit bout de code possible. Nous faisons tout cela dans l'objectif de limiter les failles que pourraient exploiter un hacker qui découvre une vulnérabilité « zero day ».

Exécuter un serveur Web pour une fonctionnalité accessoire va à l'encontre de cet objectif.

En plus de cela, héberger des applications Web sur Elasticsearch favorise une bien mauvaise pratique, celle d'exposer Elasticsearch à Internet alors qu'il devrait fonctionner sur un réseau isolé et plus sécurisé.

Exécuter des plugins de type site avec Elasticsearch 5.0

Alors que de nombreux plugins populaires comme Head, Kopf (bientôt remplacé par Cerebro) et HQ contiennent déjà des commandes pour s'exécuter en dehors d'Elasticsearch, il est facile de créer le vôtre également. Un plugin de type site est constitué de fichiers HTML statiques, JavaScript, CSS et d'images, qui peuvent être servis par le serveur Web de votre choix, même (pour un usage local) par SimpleHTTPServer de Python : 

cd my_plugin/
python -m SimpleHTTPServer 8000

Comme les plugins envoient des requêtes directement à Elasticsearch depuis le navigateur de l'utilisateur, une petite configuration est nécessaire pour ordonner à Elasticsearch d'activer le Partage des Ressources d'Origines Croisées (Cross Origin Resource Sharing).

Par exemple, vous pourriez ajouter ce qui suit au fichier de configuration elasticsearch.yml config file: 

http.cors.enabled: true
http.cors.allow-origin: /https?:\/\/localhost(:[0-9]+)?/

Le paramètre allow-origin doit être une expression régulière correspondant à l'adresse du serveur Web qui héberge le plugin. Vous trouverez plus d'informations sur les paramètres relatifs au CORS dans la documentation du module HTTP.

Si votre serveur Elasticsearch utilise la fonction de Sécurité incluse dans X-Pack (qui remplace Shield dans la version 5.0), alors vous serez également obligé d'ajouter les paramètres suivants : 

http.cors.allow-credentials: true
http.cors.allow-headers: X-Requested-With,X-Auth-Token,Content-Type, Content-Length, Authorization

Au-delà des plugins de type site

Si vous êtes créateur de plugins et souhaitez vous affranchir des restrictions inhérentes à la création d'applications avec des fichiers Web statiques, envisagez de développer un plugin Kibana à la place.

Kibana s'accompagne d'un serveur Web Node.js et les plugins incluent une fonctionnalité côté serveur. Par exemple, tous les appels à destination d'Elasticsearch peuvent être réalisés directement depuis le serveur back-end de Kibana au lieu du navigateur de l'utilisateur.

Il y a également un générateur de plugins Kibana pour vous aider à démarrer avec votre propre plugin, et une vidéo du Elastic{ON}16 décrivant le processus. Comme toujours avec Kibana, des développeurs serviables vous attendent sur le IRC et sur le forum afin de répondre à toutes vos questions.