Rudder 4 – nouvelle version de la solution de Continuous Configuration

Source: LinuxFR – les dépêches
Liens: Rudder 4 – nouvelle version de la solution de Continuous Configuration
Rudder 4 – nouvelle version de la solution de Continuous Configuration

Un peu plus de deux ans après la sortie de Rudder 3, une nouvelle version majeure voit le jour, et avec elle de nombreux changements qui distinguent encore davantage Rudder des outils de gestion de configuration classique.

Dashboard Rudder 4

Rudder est une solution libre et multiplateforme de Continuous Configuration (gestion de configuration et audit en continu), visant particulièrement les besoins d’infrastructures de production.

Sommaire

Qu’est-ce que Rudder ?

Rudder est une solution open source de Continuous Configuration qui audite le SI en continu et automatise les opérations IT de façon contrôlée et sécurisée.

Derrière le terme de Continuous Configuration, on trouve une base de gestion de configuration, alliée à des fonctionnalités d’audit en continu. La différence entre un outil de gestion de configuration traditionnel et Rudder, c’est que les changements peuvent être simulés individuellement avant d’être validés, puis vérifiés après être appliqués, et enfin tracés et maintenus dans le temps. Tout ce qui n’est pas conforme à l’état cible, auquel on souhaite rester ou accéder, remonte des alertes en temps réel, créé des rapports de dérive ou déclenche une remédiation automatique. Cela en fait un outil particulièrement adapté pour répondre aux contraintes d’infrastructures de production.

D’un point de vue pratique, Rudder permet de :

  • gérer le socle système (distribuer des clés SSH, paramétrer le DNS, gérer les utilisateurs, paramétrer les permissions sur les dossiers et fichiers, lancer des jobs, gérer les certificats, etc.) ;
  • installer, mettre à jour, et configurer des applications ;
  • appliquer et vérifier en continu les politiques de sécurité, y compris pour des normes externes (ISO 27001, PCI-DSS, PSSI de l’ANSSI, etc.).

En bref, Rudder est :

  • un outil de gestion de configuration et d’audit en continu, existant depuis 2011.
  • Libre (code sous GPLv3, documentation sous CC by-sa 2.0, avec quelques bibliothèques sous License Apache) ;
  • composé d’un serveur qui gère les configurations et la remontée de conformité (en Scala) et d’un agent de configuration (en C), qui gère Debian, Ubuntu, RHEL/CentOS, SLES, AIX ;
  • utilisé par de larges productions critiques comme la Caisse d’Épargne, BMW, Eutelsat ou Novartis ;
  • principalement développé par Normation (http://www.normation.com/fr/normation/qui-sommes-nous/), qui propose différents services autour de Rudder, tels que du support ou de la formation, ainsi que des plugins payants pour des besoins spécifiques, notamment pour le support des machines Windows.

Logo Rudder 4

Pour ceux qui veulent voir plus en détail le fonctionnement de Rudder, vous pouvez consulter le schéma d’architecture.

Rudder 4

Rudder 4.0 est sortie le 10 novembre 2016, et Rudder 4.1 le 30 mars 2017. Les axes d’évolutions de ces versions sont présentés dans la suite de l’article.

Le mode Audit

La fonctionnalité centrale de Rudder 4 est la possibilité de configurer un serveur pour n’effectuer que de la vérification de l’état de certaines règles de configuration. On peut réaliser cette configuration pour une machine complète ou pour une portion de configuration, ou bien encore au niveau global sur l’ensemble des règles de configuration et l’ensemble des machines.

Rudder offre donc maintenant deux modes : Audit et Enforce, respectivement pour vérifier l’état sans le modifier, et pour modifier le système pour atteindre l’état cible.

Audit mode

Quels sont les cas d’utilisation possibles :

  • outil d’audit pur, par exemple pour une vérification de normes (PCI-DSS, ISO 27001, etc.). À la différence d’avec un outil dédié, une fois la configuration effectuée, elle peut directement être utilisée pour configurer ;
  • validation de changements avant de les appliquer, par exemple une nouvelle configuration. Ce cas peut être vu un équivalent d’un mode dry-run classique mais potentiellement sur l’ensemble de l’infrastructure, et une granularité supérieure (portant seulement sur certains points de configuration) ;
  • validation après l’installation de Rudder sur une infrastructure existante, pour valider qu’il correspond à la configuration cible théorique, avant d’activer le mode Enforce.

Si les techniques (règles fournies par défaut à l’installation) peuvent se révéler limitées pour de l’audit, la construction des règles d’audit est particulièrement simple et accessible à l’aide du Technique Editor, un éditeur de configuration Web.

Performance

Rudder est déployé sur des parcs de taille de plus en plus importante, et d’un objectif d’une centaine de machines gérées sur un serveur avec les premières version (Rudder 2), puis de l’ordre du millier de machines (Rudder 3), la version 4 vise un ordre de grandeur d’une dizaine de milliers de machines gérées efficacement depuis un serveur.

Performance du serveur

Le travail pour passer à cette échelle a consisté en plusieurs points :

  • des tests de performance approfondis pour prioriser les améliorations ;
  • un travail sur le modèle de données de l’application, notamment dans le stockage de l’information de conformité ; les rapports de conformité attendus (correspondant aux configurations mises à disposition des machines), sont désormais stockés sous format JSON, par noeud, en un point unique, au lieu d’être répartis dans plusieurs tables. Cela simplifie grandement les calculs de conformités lors de la réception des rapports d’exécution de l’agent ;
  • une amélioration du cache interne de l’application, notamment du cache de valeurs de conformité.

L’interface Web a aussi reçu des améliorations :

  • Les ressources statiques ont maintenant une URL versionnée et sont correctement mises en cache, et la compression des ressources été activée partout.
  • Lorsque nous avons introduit le Dashboard et les graphes de changement récents, nous nous sommes tournés vers c3.js (http://c3js.org/) pour l’affichage des graphiques. Cette librairie utilise du svg, mais Firefox présente de gros problèmes de performance dans le rendu des svg. Ceci, combiné à l’usage que nous en faisons (de petits graphes dans des tableaux) engendre une baisse dramatique des performances (chaque graphique prend des centaines de millisecondes à s’afficher, ce qui bloque le navigateur et engendre un niveau d’utilisation élevé du CPU). Ce n’était pas visible avec seulement quelques graphes, mais lorsque ce nombre augmente cela pouvait complètement bloquer l’utilisation du navigateur. En 4.1, c’est terminé! Nous avons remplacé cette librairie par chart.js (http://www.chartjs.org), qui utilise un canvas pour afficher ces graphes ce qui offre une hausse des performances énorme sous Firefox.

Performance de l’agent

D’autre part, côté agent, la légèreté et la rapidité permettent de diversifier les types de déploiements vers des parcs légers (Raspberry Pi, etc.), en plus d’utiliser moins de ressources sur les machines gérées.

Nous nous sommes concentrés sur la performance de l’agent, notamment après avoir constaté de graves dégradations de performances avec des règles contenant des variables (tableaux en l’occurrence) de taille importante (plusieurs centaines d’éléments), et a abouti en version 4.1.1 à une amélioration très significative de la durée d’exécution de l’agent dans certains cas (la création de 500 utilisateurs sur une machine passe de dix minutes à une quinzaine de secondes). Un agent avec quelques règles de configuration simples s’exécute en une à deux secondes, et peut aller jusqu’à quelques dizaines de secondes pour des configurations avec plusieurs centaines d’éléments configurés, avec une consommation de RAM de quelques dizaines de Mo.

Organiser les configurations

Quand la quantité de configurations devient importante dans votre installation Rudder, il peut devenir difficile de retrouver les éléments de configuration (nœuds, règles, etc.). Pour cela, plusieurs améliorations ont été apportées :

  • Un système de tag sur les objets de configuration (règles, directives) a été ajouté. Les tags sont basés sur un système clé/valeur, pour plus de souplesse dans l’utilisation (par exemple “environnement” -> “production”). Une règle ou directive peut avoir autant de tags que souhaité, potentiellement avec la même clé.
  • Les tags sont éditables dans l’interface Web et via l’API, et sont utilisables en tant que filtre dans les champs de recherches (avec de l’auto-complétion)

Tags Rudder

Depuis Rudder 3.1, nous avons la possibilité d’utiliser des propriétés de nœuds (stockées sous forme de chaîne de caractère ou d’objet JSON) pour regrouper les nœuds basés sur des propriétés définies, et pour ajouter des données dans les “politiques” générées.

Ces propriétés ne pouvaient être que définies via l’API de Rudder, et étaient affichées dans l’interface web. De plus leur utilisation a été facilitée par l’inclusion d’un moteur JavaScript dans les champs de paramètres, permettant une manipulation simple du contenu des variables.

Dans Rudder 4.1, nous pouvons désormais ajouter ou supprimer les propriétés de nœuds directement depuis cette interface, depuis l’onglet “Properties” dans les détails d’un nœud. Vous pouvez aussi créer de nouvelles propriétés, dont les valeurs peuvent aussi bien être une simple chaîne de caractères, ou bien des données au format JSON pour les structures plus complexes.

Pilotage via l’API

Le cycle de développement de la version 4 a permis l’ajout de deux nouvelles possibilités dans l’API.

La première donne simplement accès à la configuration du serveur Rudder lui-même, ce qui permet d’automatiser des changements de configuration. Elle permet par exemple de modifier la fréquence d’exécution des agents, ou la durée de rétention des sauvegardes des fichiers modifiés par les agents sur les nœuds gérés, ou encore de réaliser des snapshots de la configuration de Rudder.
La deuxième API introduite concerne le déclenchement d’agents. En effet, l’agent Rudder est autonome et se connecte régulièrement au serveur Rudder figurant dans sa configuration pour obtenir la dernière version des configurations à appliquer (par défaut, toutes les cinq minutes). Ainsi, quand un changement de configuration cible est réalisé sur le serveur, la propagation s’étale sur plusieurs minutes (ou dizaines de minutes, selon de délai d’exécution configuré).

Pour permettre d’appliquer au plus vite un changement de configuration en cas de besoin, une nouvelle API a été mise en place. Elle permet, depuis le serveur, de déclencher une exécution des agents sur les nœuds.

Cette API a deux modes principaux :

  • déclenchement sur un ensemble de nœuds, et obtention de la sortie de l’agent ;
  • déclenchement asynchrone d’exécution de l’agent sur l’ensemble des nœuds, sans attendre le résultat.

Rudder est maintenant totalement pilotable par API, que ce soit au niveau de la création et gestion des règles de configuration ou de l’administration de Rudder, ou de l’extraction d’information de conformité. Les API permettent en général de personnaliser le fonctionnement de Rudder et d’automatiser certaines opérations spécifiques (acceptation de nouvelles machines sur un serveur Rudder, édition de configurations, etc.). Pour faciliter la manipulation de l’API, une interface en ligne de commande et une bibliothèque Python existent.

Note : Comment se passe la modification de configuration sur le serveur, que ce soit via l’API ou l’interface Web ? Le code de configuration est en fait stocké dans un dépôt Git sur le serveur, permettant ainsi une modification via l’interface ou directement dans le code. De plus une partie des fonctionnalités liées à la configuration (snapshot, annulation d’un changement, log des événements) est directement basée sur l’utilisation du dépôt git sous-jacent.

Ergonomie de l’interface web

L’interface de Rudder n’avait pas beaucoup évoluée depuis la sortie de la version 3.0, tandis que le logiciel n’a cessé d’intégrer de nouvelles fonctionnalités.
La version 4.0 fut l’occasion parfaite de rajeunir l’image de Rudder en lui offrant une nouvelle interface, plus moderne et responsive.

Voici une liste non exhaustive des principales améliorations :

  • nouvelle disposition du menu ;
  • ajout d’un champ de recherche global, portant sur toutes les entités (machines, configuration, etc.) présents dans Rudder. Ce champ de recherche dispose aussi d’un langage de requêtage simple pour effectuer une recherche sur un type d’objet ou un champ précis ;
  • intégration du nouveau logo ;
  • nouveau thème pour l’arbre des groupes, directives, règles, etc.
  • la plupart des formulaires intègrent désormais le framework Bootstrap.

Quicksearch Rudder

Autour du développement

Lors du travail sur Rudder 4, les processus de développement ont été améliorés. Nous avons ajouté de nouvelles possibilités à notre outil de développement “rudder-dev”, notamment la possibilité d’ouvrir un ticket de correction directement depuis la ligne de commande. Nous avons, en plus de cet outil, créé un bot github qui teste les pull requests et effectue les merge dans les branches supérieures automatiquement quand c’est possible. Sinon, il fournit la commande pour l’effectuer manuellement (cf https://github.com/Normation/rudder/pull/1616 par exemple). Cela a permis d’éviter des problèmes lors du merge de branches contenant plusieurs correctifs différents, quand cela n’avait pas été fait immédiatement après le merge dans la branche de destination.

De plus nous sommes en train de modifier le système de priorisation des tickets pour coller au mieux aux besoins de la majorité des utilisateurs et la cohérence de la roadmap.

Suite à une rétrospective sur le développement de la 4.0, nous avons lancé de nouveaux canaux de discussion avec les utilisateurs et contributeurs, notamment une nouvelle FAQ et un blog autour du développement.

Nous avons aussi participé cette année encore au Configuration Management Camp à Gand. Nous avions cette année une room dédiée, et avons accueilli cinq talks à cette occasion, en plus de notre intervention au sein de la main track de l’événement.

Et maintenant ?

La prochaine fonctionnalité importante sera le développement d’un agent pour Windows, basé sur l’outil natif DSC (Desired State Configuration), intégré à Powershell depuis la version 4, et désormais open source.

Nous souhaitons de plus utiliser les possibilités introduites en 4.0 et 4.1 pour proposer des fonctionnalités plus avancées, comme par exemple un déploiement progressif de configuration (ramp-up) basé sur les premiers retours de conformité.

Pour en savoir plus et tester Rudder, vous pouvez:

Lire les commentaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *