Auditer un rôle Ansible Galaxy avant utilisation : checklist en 7 axes

Avant d'utiliser un rôle Galaxy ou GitHub dans votre projet, vous devez l'auditer. Tous les rôles Galaxy ne se valent pas : certains sont abandonnés, mal testés, ou compromis (typosquatting, takeover). Cette checklist en 7 axes vous donne un protocole reproductible pour évaluer un rôle en 5-10 minutes et décider d'adopter, forker, ou refuser.

Ce que vous allez apprendre

• Les 7 axes d'audit d'un rôle Ansible.
• Critères mesurables par axe (pas de subjectivité).
• Calculer un score d'audit (10/10).
• Quand adopter, forker, refuser un rôle.
• Reconnaître les patterns d'attaque supply chain.

Pourquoi auditer ?

Un rôle Galaxy compromis peut :

• Exfiltrer des secrets (/etc/shadow, clés SSH).
• Installer un backdoor (cron job persistant).
• Modifier sshd_config (autorisation root via clé).
• Inclure des dépendances malicieuses (en cascade).

L'audit prévient ces risques. 5-10 minutes par rôle Galaxy avant adoption.

Checklist en 7 axes

Les sept axes sont rangés du plus décisif au plus secondaire, et leur poids suit le nombre de critères qu'ils portent : la qualité du code et la sécurité comptent 6 points chacune, la compatibilité et l'idempotence 3. Chaque axe se termine par ses drapeaux rouges, c'est-à-dire ce qui doit arrêter l'audit sur-le-champ plutôt que coûter un point.

Axe 1, Mainteneur (4 points)

• Auteur connu ou organisation officielle (Red Hat, geerlingguy, ansible-collections, etc.)
• Date du dernier commit < 12 mois
• Issues récentes répondues (au moins 50 % de réponses)
• CHANGELOG.md à jour avec versions

Drapeaux rouges : auteur sans nom complet (juste un pseudo), 0 contribution depuis 18 mois, issues abandonnées.

Axe 2, Qualité du code (6 points)

• meta/main.yml complet (galaxy_info, platforms, dependencies)
• meta/argument_specs.yml présent (validation auto des entrées)
• README.md documente toutes les variables
• FQCN partout dans tasks/ (ansible.builtin.dnf, pas juste dnf)
• Pas de command: ou shell: sans creates:/removes:
• Variables préfixées par le nom du rôle (nginx_*, pas version)

Drapeaux rouges : variables génériques (version, port), tâches non-idempotentes, pas de meta.

Axe 3, Sécurité (6 points)

• Aucune clé ou secret dans le code
• Aucune URL de download non-HTTPS (http://...)
• Pas de téléchargement sans checksum:
• Permissions strictes sur les fichiers déployés (mode: 0640 ou plus restrictif)
• Pas de become_user: root non justifié
• Validation des entrées via argument_specs.yml

Drapeaux rouges : curl http://... dans une tâche, mode 0777, secrets en clair (même partiels), command: avec input non échappé.

Axe 4, Tests (4 points)

• molecule/ présent avec scénario default
• verify.yml ou tests testinfra
• .ansible-lint présent (idéalement profil production)
• CI/CD (GitHub Actions, GitLab CI) actif

Drapeaux rouges : zéro test, dossier tests/ vide ou non maintenu, CI éteinte.

Axe 5, Compatibilité (3 points)

• Platforms déclarées dans meta/main.yml matchent votre environnement
• min_ansible_version ≤ votre version d'Ansible
• Pas de dépendances obsolètes (yum_module, etc.)

Drapeaux rouges : platforms: [Ubuntu 18.04] (EOL), min_ansible_version: 2.5 (ancienne).

Axe 6, Idempotence (3 points)

C'est l'axe le plus rapide à vérifier, et le seul qui demande d'exécuter le rôle plutôt que de le lire. Deux passages du même playbook suffisent : un rôle correct rend changed=0 au second. Les deux autres critères cherchent ce qui casse cette propriété, un changed_when: true posé par commodité et un ignore_errors: true qui masque un échec réel.

• Test molecule converge && molecule verify retourne changed=0 au 2e run
• Pas de changed_when: true non justifié
• Pas de ignore_errors: true sur les tâches critiques

Comment tester :

ansible-galaxy role install <role>
# Créer un playbook test
ansible-playbook test.yml      # 1er run
ansible-playbook test.yml      # 2e run → changed=0 attendu

Axe 7, Maintenabilité (4 points)

Ce dernier axe ne mesure pas la correction du rôle mais le coût de sa reprise, le jour où son mainteneur disparaît et où vous héritez du fork. Il regarde donc ce qui se lit : des commentaires sur les passages retors, des valeurs par défaut défendables, une profondeur de rôles maîtrisée, et des tâches groupées par responsabilité plutôt qu'en une longue liste.

• Code commenté (au moins les sections complexes)
• Variables avec defaults raisonnables
• Pas de rôle imbriqué > 2 niveaux
• Tâches groupées par responsabilité (install / configure / start / verify)

Le score

Le score n'est pas une note scolaire, c'est une estimation du travail de reprise. Un point par critère coché, aucune pondération subjective : c'est ce qui rend l'audit reproductible d'une personne à l'autre, et discutable en revue de code. Les quatre paliers ci-dessous traduisent le total en décision.

Un point par critère coché, soit 30 points répartis sur les sept axes :

Score	Décision
27-30/30	Rôle de qualité production. Adopter.
20-26/30	Acceptable. Adopter avec un audit de sécurité complémentaire.
14-19/30	Risqué. Envisager un fork pour corriger les manques, ou chercher une alternative.
moins de 14/30	Refuser : l'effort de maintenance dépasse le gain.

Glissez pour voir

Patterns d'attaque à reconnaître

Les trois attaques qui suivent ne visent pas le code du rôle mais le moment où vous le choisissez. Aucune ne se détecte par la lecture des tâches, ce qui les rend complémentaires des sept axes : on peut auditer soigneusement le mauvais rôle. Chacune est suivie de sa parade, et les trois parades sont des réflexes, pas des outils.

Typosquatting

Un attaquant publie comunity.general (1 m manquant) en espérant des fautes de frappe.

Mitigation : copier-coller depuis Galaxy, jamais retaper. Vérifier le mainteneur officiel (community.general = ansible-collections/community.general).

Takeover de namespace

Un namespace abandonné est récupéré par un attaquant qui publie une version compromise.

Mitigation : préférer les namespaces d'organisations (redhat.*, ansible.*, geerlingguy.*) plutôt que d'individus inconnus.

Dépendances malicieuses

Une collection peut dépendre d'autres collections, qui dépendent de packages Python compromis.

Mitigation : cat ~/.ansible/collections/.../MANIFEST.json après install pour voir l'arbre de dépendances.

Outils complémentaires

Ces quatre outils automatisent une partie de la grille, jamais sa totalité : ils repèrent des motifs, pas des intentions. Les deux premiers couvrent la qualité et la syntaxe, le troisième l'intégrité de ce qui a été installé, le dernier pousse l'analyse jusqu'aux fuites de secrets. Aucun ne remplace la lecture de tasks/main.yml.

Outil	Usage
ansible-lint --profile=production	Vérification automatique de qualité
yamllint	Vérification syntaxe YAML
ansible-galaxy collection verify	Intégrité cryptographique
Steampunk Spotter (commercial)	Audit avancé : secrets leak, FQCN, suggestions

Glissez pour voir

Mettre en pratique

Une grille d'audit ne prouve sa valeur que confrontée à du code réel, avec ses zones grises. Le lab vous fait installer un rôle Galaxy largement diffusé, remplir une checklist de plus de vingt points de contrôle, relever les anti-patterns décrits plus haut, puis conclure par une décision argumentée : adopter, forker ou refuser. La vérification porte sur les points d'audit effectivement relevés et sur la cohérence du score, pas sur le verdict que vous auriez préféré.

Lab pratique

Auditer un rôle Galaxy avant de l'adopter

$ dsoxlab run galaxy-auditer-role-existant

Environnement : Shell·Durée : ~40 min

Validé : la sortie produite est comparée au résultat attendu.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run galaxy-auditer-role-existant
dsoxlab check galaxy-auditer-role-existant

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pièges courants

Ces cinq situations arrivent après l'audit, ce qui les rend particulièrement frustrantes : la grille a bien été remplie, et le rôle pose quand même problème. Trois d'entre elles viennent du périmètre de l'audit, qui juge le rôle et non son adéquation à votre environnement. Les deux autres viennent du temps qui passe.

Symptôme	Cause	Fix
Rôle adopté trop vite, casse en prod	Pas d'audit	Imposer la checklist 7 axes en code review
Score 10/10 mais bug en prod	Test sur la mauvaise distro	Tester sur votre distro cible avant adoption
Mainteneur disparaît post-adoption	Pas de plan de fallback	Forker dans votre namespace dès l'adoption
Faille découverte dans un rôle utilisé	Pas de monitoring CVE	Suivre ansible-galaxy collection verify régulièrement
Vérification cryptographique optionnelle ignorée	Galaxy 2024+	Activer signatures: dans requirements.yml

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• 7 axes d'audit : mainteneur, code, sécurité, tests, compatibilité, idempotence, maintenabilité.
• Score sur 30, un point par critère : adopter au-dessus de 27, refuser en dessous de 14.
• Drapeaux rouges : variables non préfixées, command: non idempotent, pas de tests.
• Patterns d'attaque : typosquatting, takeover, dépendances malicieuses.
• Forker dans votre namespace dès l'adoption pour fallback.
• molecule test 2 fois = test d'idempotence rapide.

Pour aller plus loin

• Vault dans les rôles : cloisonner les secrets qu'un rôle adopté va recevoir, une fois l'audit passé.
• HashiCorp Vault / OpenBao : garder les secrets hors du dépôt, ce qui limite la casse si un rôle tiers dérape.
• Construire un EE custom : figer la version auditée et ses dépendances dans une image, pour que l'audit reste valable dans le temps.

×

📖 Voir la documentation →