Automatisation Ansible pour une Infrastructure Reproductible et Auditée

Terraform provisionne les ressources d'infrastructure — machines virtuelles, réseaux, bases de données, enregistrements DNS. Ansible configure ce qui tourne sur ces ressources — paramètres du système d'exploitation, paquets, utilisateurs, services et configuration applicative. Les deux outils sont complémentaires : Terraform crée le nœud, Ansible le durcit et le configure. Nous utilisons les sorties Terraform comme inventaire dynamique Ansible afin que le passage de relais soit automatique et que l'état reste cohérent dans les deux outils.

Ansible se connecte aux nœuds gérés via SSH (Linux/macOS) ou WinRM (Windows), pousse un module Python temporaire, l'exécute puis le supprime. Il n'y a aucun daemon ni agent persistant à maintenir. Le nœud de contrôle a besoin d'un accès SSH et d'un utilisateur disposant de droits d'élévation de privilèges sur chaque cible. Ce modèle accélère l'intégration — un nouvel hôte est joignable dès que SSH est ouvert — et élimine toute une classe de problèmes de mise à jour d'agents et de connectivité propres aux outils à base d'agents.

Nous utilisons deux couches. ansible-vault chiffre les fichiers de variables au repos avec AES-256, de sorte que les secrets sont en sécurité dans Git. Pour les identifiants dynamiques et de courte durée — clés d'API cloud, mots de passe de bases de données, certificats TLS — nous intégrons HashiCorp Vault via le plugin de recherche community.hashi_vault. Vault émet des secrets de courte durée lors de l'exécution du playbook ; ils ne touchent jamais le disque. Le mot de passe du vault lui-même est stocké dans un gestionnaire de secrets et injecté dans AWX en tant qu'identifiant, ce qui maintient la chaîne entière chiffrée.

L'idempotence signifie qu'exécuter un playbook dix fois produit le même résultat qu'une seule exécution : les tâches déjà dans l'état souhaité signalent « ok » et ne modifient rien. C'est important car cela rend les playbooks sûrs à relancer pour corriger les dérives, permet de planifier des exécutions quotidiennes de référence sans effets de bord et simplifie le dépannage — un nombre de tâches modifiées supérieur à zéro indique immédiatement une dérive réelle. Nous auditons chaque rôle pour identifier les tâches shell et command non idempotentes et les remplaçons par des équivalents modulaires idempotents.

Nous utilisons Molecule, le framework de test de référence pour les rôles Ansible. Chaque rôle est livré avec au moins un scénario Molecule : un scénario basé sur Docker pour un retour rapide en CI et, pour les rôles nécessitant systemd ou des fonctionnalités noyau, un scénario basé sur une machine virtuelle exécuté selon un calendrier. ansible-lint vérifie le style et les erreurs courantes sur chaque pull request. Les scénarios de test couvrent la convergence (application), l'idempotence (réapplication, zéro changement attendu) et optionnellement la vérification (assertion de l'état final). Aucun rôle n'atteint la production sans une exécution CI réussie.

AWX (open source) et Ansible Automation Platform (le produit commercial de Red Hat) ajoutent une interface web, une API REST, du RBAC, un coffre-fort d'identifiants, une planification des tâches et des journaux d'exécution complets par-dessus Ansible Core. Les équipes déclenchent des exécutions de playbooks depuis un portail en libre-service ou un webhook CI sans avoir besoin d'accès CLI. Le RBAC limite chaque équipe aux playbooks et inventaires qui la concernent. Les journaux de tâches avec détail par tâche satisfont aux exigences de preuves SOC 2. Nous déployons AWX sur Kubernetes pour la haute disponibilité et l'intégrons à votre fournisseur LDAP ou SSO existant.

Les rôles de durcissement CIS appliquent les contrôles de configuration du CIS Benchmark pour un système d'exploitation donné — RHEL, Ubuntu, Amazon Linux ou Windows Server. Chaque contrôle correspond à une ou plusieurs tâches Ansible qui vérifient et appliquent le paramètre requis : paramètres noyau, options de montage des systèmes de fichiers, activation des services, configuration PAM, paramètres du daemon SSH, règles d'audit et listes de paquets. Les contrôles sont étiquetés afin que des éléments individuels puissent être ignorés pour des exceptions documentées. Nous testons chaque rôle avec Molecule pour confirmer que les contrôles CIS s'appliquent proprement et de manière idempotente, et nous produisons un rapport lisible par machine des contrôles appliqués par rapport aux contrôles ignorés pour les auditeurs.