Sommaire
Qu’est‐ce que Rudder ?
Rudder est une solution libre de Continuous Configuration qui audite le système d’information (SI) en continu et automatise les opérations logicielles 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ée 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’infrastructure de production.
D’un point de vue pratique, Rudder permet de :
- gérer le socle système (distribuer des clefs SSH, paramétrer le DNS, gérer les utilisateurs, paramétrer les permissions sur les dossiers et fichiers, lancer des tâches, 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 GPL v3, documentation sous CC by-SA 2.0, avec quelques bibliothèques sous licence 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 et 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 greffons payants pour des besoins spécifiques, notamment pour le support des machines Windows.
Pour ceux qui veulent voir plus en détails le fonctionnement de Rudder, vous pouvez consulter le schéma d’architecture.
Rudder 4
Rudder 4.0 est sorti 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.
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 comme un équivalent d’un mode dry‐run classique, mais potentiellement sur l’ensemble de l’infrastructure et avec 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 tailles de plus en plus importantes 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 nœud, 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 a été activée partout ;
- lorsque nous avons introduit le Dashboard et les graphes de changements récents, nous nous sommes tournés vers c3.js pour l’affichage des graphiques. Cette bibliothèque 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 processeur). Ce n’était pas visible avec seulement quelques graphes, mais lorsque ce nombre augmente cela pouvait complètement bloquer l’utilisation du navigateur. En version 4.1, c’est terminé ! Nous avons remplacé cette bibliothèque par chart.js, qui utilise un canevas 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 mémoire vive de quelques dizaines de mégaoctets.
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 d’étiquettes (tags) sur les objets de configuration (règles, directives) a été ajouté. Les étiquettes sont basées sur un système clef‐valeur, pour plus de souplesse dans l’utilisation (par exemple : “environnement” → “production”). Une règle ou directive peut avoir autant d’étiquettes que souhaité, potentiellement avec la même clef ;
- les étiquettes sont éditables dans l’interface Web et via l’API, et sont utilisables en tant que filtres dans les champs de recherches (avec de l’auto‐complétion).
Depuis Rudder 3.1, nous avons la possibilité d’utiliser des propriétés de nœuds (stockées sous forme de chaînes de caractères ou d’objets 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 définies que 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, via 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 instantanés (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’informations 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, il existe une interface en ligne de commande et une bibliothèque Python.
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 (instantané, annulation d’un changement, journal 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é 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ésentes 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 cadriciel Bootstrap.
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 demandes d’intégration Git (pull requests) et effectue les fusions (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 de la fusion de branches contenant plusieurs correctifs différents, quand cela n’avait pas été fait immédiatement après la fusion 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 être plus en cohérence avec la feuille de route.
Suite à une rétrospective sur le développement de la version 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 salle dédiée et avons accueilli cinq discussions à 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 en outre utiliser les possibilités introduites dans les versions 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 :
