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. Toutes 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

Axe 1, Mainteneur (3 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 (4 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é (5 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 (3 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é (2 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 (1 point)

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é (1 point)

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

Sur 19 critères au total :

Score	Décision
17-19/19	✅ Rôle de qualité production. Adopter.
13-16/19	🟡 Acceptable. Adopter avec audit complémentaire (vérif sécurité approfondie).
9-12/19	🟠 Risqué. Considérer un fork (corriger les manques) ou chercher une alternative.
< 9/19	🔴 Refuser. Trop d'effort de maintenance.

Patterns d'attaque à reconnaître

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

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

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é.

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 dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd 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.

Pièges courants

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

À retenir

7 axes d'audit : mainteneur, code, sécurité, tests, compatibilité, idempotence, maintenabilité.
Score sur 19, adopter ≥ 17, refuser < 9.
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.