Concepts Rudder : Techniques, Directives, Groupes, Règles et Policy Mode

Avant d'installer et de créer votre première configuration Rudder, il est essentiel de comprendre comment l'outil organise la gestion de configuration. Rudder repose sur 4 concepts structurants (Technique, Directive, Groupe, Règle) et un concept transversal clé : le Policy Mode (Audit/Enforce).

Ce guide vous explique chaque concept, comment ils interagissent, et pourquoi cette organisation facilite la gestion d'infrastructures complexes.

La vision d'ensemble

Imaginez que vous voulez installer et configurer Apache sur tous vos serveurs web. Voici comment Rudder structure cette tâche :

Concepts Rudder : Règle, Directive, Technique et Groupe

En résumé :

La Technique définit comment faire quelque chose (installer Apache, gérer SSL...)
La Directive configure quoi faire exactement (activer SSL, port 443, chemin des certificats...)
Le Groupe définit qui est concerné (mes serveurs web)
La Règle combine Directive + Groupe pour dire "appliquer ceci à ceux-là"

Les Techniques : le "comment"

Qu'est-ce qu'une Technique ?

Une Technique est un modèle réutilisable qui décrit comment réaliser une tâche de configuration. Concrètement, c'est une suite ordonnée d'appels de méthodes (installer un paquet, écrire un fichier, démarrer un service) exposant des paramètres que vous renseignerez ensuite. La Technique ne cible aucune machine et ne fixe aucune valeur : elle définit la mécanique, pas le contenu.

Les Techniques intégrées

Rudder est livré avec des dizaines de Techniques prêtes à l'emploi couvrant les besoins courants :

Catégorie	Exemples de Techniques
Paquets	Package management, APT repository
Fichiers	File content, File template, Permissions
Services	Service management, Systemd service
Utilisateurs	User management, Group management, SSH keys
Sécurité	Sudo management, SSH configuration, Firewall
Web	Apache HTTP Server, Nginx
Bases de données	PostgreSQL, MySQL
Monitoring	NTP, Time settings

Ces Techniques sont visibles dans Configuration Management → Techniques.

Créer ses propres Techniques

Pour des besoins spécifiques, vous pouvez créer vos propres Techniques de deux façons :

1. Via le Technique Editor (recommandé)

L'éditeur visuel intégré permet de créer des Techniques sans écrire de code :

Allez dans Configuration Management → Techniques
Cliquez sur Create
Ajoutez des "blocs" de configuration par glisser-déposer
Définissez les paramètres que l'utilisateur pourra renseigner

2. Via YAML/JSON (avancé)

Pour les utilisateurs expérimentés, les Techniques peuvent être écrites en code et versionnées dans Git :

# Exemple simplifié de Technique en YAML
name: "Mon application métier"
description: "Installe et configure notre app interne"
version: "1.0"
parameters:
  - name: APP_VERSION
    description: "Version de l'application"
    default: "latest"
  - name: APP_PORT
    description: "Port d'écoute"
    default: "8080"
method_calls:
  - method: package_present
    params:
      name: "mon-app=${APP_VERSION}"
  - method: service_started
    params:
      name: "mon-app"

Les Directives : le "quoi"

Qu'est-ce qu'une Directive ?

Une Directive est une instance paramétrée d'une Technique. Elle prend une Technique et lui donne des valeurs concrètes.

Pourquoi séparer Technique et Directive ?

Cette séparation offre une grande flexibilité. Imaginons que vous gérez :

Des serveurs web de production (haute disponibilité)
Des serveurs web de staging (configuration de test)

Avec une seule Technique "Apache HTTP Server", vous créez deux Directives :

Directive	Configuration
"Apache Production"	`max_workers: 400`, `enable_ssl: true`, `log_level: warn`
"Apache Staging"	`max_workers: 50`, `enable_ssl: false`, `log_level: debug`

Créer une Directive

Choisissez une Technique

Dans Configuration Management → Directives, parcourez les Techniques disponibles.
Créez la Directive

Cliquez sur une Technique, puis Create Directive.
Remplissez les paramètres

Chaque paramètre a :
- Un nom et une description
- Une valeur par défaut (modifiable)
- Parfois des options (menu déroulant, checkbox...)
Nommez et documentez

Donnez un nom explicite qui indique l'usage : "NTP - Serveurs Europe" plutôt que "NTP directive 1".
Sauvegardez

La Directive existe mais n'est appliquée à personne tant qu'elle n'est pas associée à une Règle.

Bonnes pratiques pour les Directives

Ces trois habitudes règlent le même problème : une Directive mal nommée ou non documentée devient illisible dès que votre parc en compte des dizaines. Le premier point est le plus rentable, un nom explicite portant le contexte (rôle, environnement) évite les collisions du type « NTP directive 1 » et rend la liste des Directives directement exploitable, sans avoir à ouvrir chacune pour savoir ce qu'elle fait.

Un nom explicite qui indique le contexte : "SSH - Bastion servers", "Users
- Dev team"
Documenter les choix de paramétrage dans la description
Versionner les Directives importantes via l'API ou Git

Les Groupes : le "qui"

Qu'est-ce qu'un Groupe ?

Un Groupe est un ensemble de nodes (machines) partageant des caractéristiques communes. Les Groupes définissent à qui s'appliquent les configurations.

Types de Groupes

Rudder propose deux types de Groupes :

Groupes dynamiques

Les membres sont définis par des critères. La liste se met à jour automatiquement quand de nouvelles machines correspondent aux critères.

Exemple : "Toutes les machines avec OS = Ubuntu 22.04"

Groupes statiques

Les membres sont définis manuellement. Vous ajoutez/retirez explicitement chaque machine.

Exemple : "Les 3 serveurs du projet Alpha"

Les critères de Groupes dynamiques

Les Groupes dynamiques utilisent des critères basés sur l'inventaire collecté par Rudder :

Catégorie	Exemples de critères
Système	OS, version, architecture, kernel
Réseau	Hostname, adresse IP, nom de domaine
Matériel	RAM, CPU, fabricant, modèle
Logiciel	Paquets installés, version
Custom	Variables définies par vous

Exemples de requêtes dynamiques :

# Tous les serveurs Debian 12
OS Type = Debian AND OS Version = 12

# Machines avec plus de 8 Go de RAM
Physical Memory > 8192

# Serveurs dont le hostname commence par "web-"
Hostname matches ^web-.*

# Machines ayant nginx installé
Software = nginx

Groupes système

Rudder crée automatiquement des Groupes spéciaux :

All nodes, Toutes les machines acceptées
All Linux nodes, Toutes les machines Linux
All Windows nodes, Toutes les machines Windows
Rudder server, Le serveur Rudder lui-même

Ces Groupes ne peuvent pas être supprimés mais peuvent être utilisés dans vos Règles.

Organisation recommandée

Organisez vos Groupes en catégories logiques :

Organisation recommandée des Groupes Rudder

Les Règles : l'assemblage final

Qu'est-ce qu'une Règle ?

Une Règle est le lien entre une Directive et un Groupe. Elle répond à la question : "Appliquer quoi à qui ?"

Anatomie d'une Règle

Le schéma ci-dessous montre les trois éléments qui composent toute Règle : la ou les Directives appliquées, le ou les Groupes ciblés, et le statut qui décide si l'ensemble est actif. Lisez-le de gauche à droite, c'est l'ordre dans lequel vous remplirez le formulaire de création, et retenez que rien ne se produit tant que le statut n'est pas passé sur activé.

Anatomie d'une Règle Rudder : Directives, Groupes et Statut

Plusieurs Directives, plusieurs Groupes

Une Règle peut inclure :

Plusieurs Directives, Pour regrouper des configurations liées
Plusieurs Groupes, Pour cibler différents ensembles de machines

Exemple concret :

La Règle "Baseline sécurité" pourrait inclure :

Directives : SSH durcissement + Firewall + NTP + Sudo
Groupes : Production + Staging

Créer une Règle

Allez dans Configuration Management → Rules
Cliquez sur Create
Nommez la Règle

Choisissez un nom descriptif : "Baseline Linux - Production" plutôt que "Rule 1".
Sélectionnez les Directives

Cochez les Directives à inclure. Vous pouvez en ajouter plusieurs.
Sélectionnez les Groupes

Cochez les Groupes ciblés. Une machine dans plusieurs Groupes recevra la Directive une seule fois.
Activez la Règle

Par défaut, les nouvelles Règles sont désactivées. Activez-la quand vous êtes prêt.
Sauvegardez

Les nodes concernés recevront la configuration à leur prochaine exécution (toutes les 5 minutes par défaut).

États d'une Règle

Au quotidien, seuls deux états comptent vraiment : Enabled et Disabled, qui décident si la Règle est poussée aux agents ou simplement conservée. Le désactivé est votre interrupteur de sécurité : il neutralise instantanément une Règle sans la supprimer ni perdre son paramétrage, ce qui est précieux quand un déploiement dérape et qu'il faut revenir à l'état antérieur au prochain passage de l'agent.

État	Signification
Enabled	La Règle est active et sera appliquée
Disabled	La Règle existe mais n'est pas appliquée
Draft	En cours d'édition, non sauvegardée

Le Policy Mode : Audit vs Enforce

Un concept transversal essentiel dans Rudder est le Policy Mode. Il détermine comment l'agent se comporte face à une non-conformité.

Les deux modes

Mode Enforce

L'agent modifie le système si nécessaire pour atteindre l'état souhaité. C'est le mode par défaut.

→ Si nginx n'est pas installé, Rudder l'installe.

Mode Audit

L'agent vérifie l'état du système et rapporte les écarts, sans rien modifier.

→ Si nginx n'est pas installé, Rudder le signale mais ne l'installe pas.

Pourquoi utiliser le mode Audit ?

Le mode Audit est précieux dans plusieurs situations :

Évaluer l'impact d'une nouvelle politique avant de l'appliquer
Auditer un parc existant pour mesurer la conformité actuelle
Démontrer la conformité à un auditeur sans risquer de modifier les systèmes
Tester une Directive sur un environnement de production sensible

Où configurer le Policy Mode ?

Le mode peut être défini à trois niveaux (du plus global au plus précis) :

Niveau	Configuration	Héritage
Global	Settings → General	S'applique partout par défaut
Directive	Dans chaque Directive	Surcharge le mode global
Node	Dans les propriétés du node	Surcharge tout pour ce node

Règle de priorité : Si un override est autorisé, le mode Audit gagne toujours. Si une Directive est en Enforce mais le node en Audit, le résultat est Audit.

Workflow recommandé

Créez votre Directive en mode Audit

Configurez le Policy Mode sur "Audit" dans les paramètres de la Directive.
Appliquez et observez

Déployez la Règle et consultez les rapports de conformité. Les éléments non-conformes apparaissent en orange (audit-non-compliant).
Analysez les écarts

Vérifiez que les modifications prévues correspondent à vos attentes. Aucun système n'est modifié à ce stade.
Passez en mode Enforce

Une fois validé, changez le Policy Mode en "Enforce" (ou "Global" si le défaut est Enforce).
Vérifiez les réparations

Les éléments passent en bleu (repaired) puis en vert (success) une fois conformes.

Lecture des rapports par mode

La même couleur ne veut pas dire la même chose selon le mode, c'est le piège de lecture le plus courant. En Enforce, le bleu signale une réparation effectuée : l'agent a modifié le système. En Audit, ce bleu n'apparaît jamais puisque rien n'est modifié ; un écart y ressort en orange. Avant d'interpréter un rapport, vérifiez donc toujours dans quel Policy Mode tournait le node concerné.

Couleur	Mode Enforce	Mode Audit
🟢 Vert	Conforme, rien à faire	Conforme, rien à signaler
🔵 Bleu	Réparé (modification appliquée)	-
🟠 Orange	-	Non-conforme (écart détecté)
🔴 Rouge	Erreur (réparation échouée)	Erreur (vérification échouée)

Comment tout s'articule

Récapitulons avec un exemple complet :

Scénario

Vous voulez que tous vos serveurs web aient :

Le paquet nginx installé
Le service nginx démarré
Un fichier de configuration standardisé

Étapes dans Rudder

Technique : Vous utilisez la Technique intégrée "Package management" et "Service management" (ou créez une Technique custom "Nginx standard")
Directive : Vous créez une Directive "Nginx Production" avec :
- Package : nginx
- Service : nginx
- Config : /etc/nginx/nginx.conf avec votre contenu
Groupe : Vous créez un Groupe dynamique "Serveurs web" avec le critère :
- Hostname matches ^web-.* OU
- Tag webserver = true
Règle : Vous créez la Règle "Nginx sur serveurs web" qui lie :
- Directive "Nginx Production"
- Groupe "Serveurs web"

Ce qui se passe ensuite

Une fois la Règle activée, vous n'avez plus rien à faire : la boucle suivante s'exécute d'elle-même, à intervalle régulier. Le point à comprendre est que c'est l'agent qui tire la configuration, node par node, à chaque cycle de cinq minutes par défaut ; le serveur ne pousse rien de façon immédiate. Une modification que vous venez de sauvegarder met donc jusqu'à un cycle complet avant d'atteindre toutes les machines.

Toutes les 5 minutes, chaque agent contacte le serveur
Le serveur calcule les politiques applicables à chaque node
L'agent reçoit les politiques et les applique
L'agent rapporte l'état de conformité (succès, réparation, erreur)

Pièges courants

Directive sans Règle

Une Directive seule ne fait rien. C'est juste une configuration "en attente". Il faut créer une Règle pour l'appliquer.

Règle trop large

Évitez d'appliquer une Règle au groupe "All nodes" sans réflexion. Testez d'abord sur un petit groupe.

Conflits de Directives

Si deux Directives modifient le même fichier avec des contenus différents, le résultat peut être imprévisible. Planifiez vos configurations pour éviter les chevauchements.

Groupes dynamiques trop complexes

Des critères trop complexes rendent le débogage difficile. Préférez des critères simples et créez plusieurs Groupes si nécessaire.

À retenir

Technique = Comment faire (le modèle réutilisable)
Directive = Quoi faire exactement (les paramètres concrets)
Groupe = Qui est concerné (ensemble de machines)
Règle = L'assemblage Directive + Groupe
Policy Mode = Audit (vérifier) ou Enforce (corriger)
Les Groupes dynamiques se mettent à jour automatiquement selon les critères
Une Directive sans Règle n'est appliquée nulle part
Commencez en Audit, passez en Enforce une fois validé
Testez toujours sur un petit groupe avant de déployer largement

Guides de cette série

Introduction Rudder Présentation générale et positionnement par rapport à Ansible/Puppet.

Installation Installer le serveur et les agents Rudder.

Premier cas d'usage Mettre en pratique les concepts avec votre première configuration.

Conformité et audit Modes Audit/Enforce et Rudder Score.

Plugin CVE Détection automatique des vulnérabilités.

Plugin System Updates Campagnes de mises à jour planifiées.

Plugin CIS Benchmarks Durcissement selon les référentiels CIS.

Plugin OpenSCAP Audits de conformité SCAP automatisés.