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.

Avant d'ajouter un rôle Galaxy à votre requirements.yml, vérifier ces 7 axes :

Axe	Vérifier	Drapeau rouge
1. Auteur	Activité GitHub, autres rôles publiés, organisation reconnue	Compte créé hier, 0 followers
2. Activité	Dernier commit < 1 an, issues ouvertes traitées	Dernier commit > 2 ans, 100 issues sans réponse
3. Tests	Présence de Molecule, CI passante, badge de couverture	Aucun test, pas de CI
4. README	Variables documentées, exemples, prérequis OS	README vide ou générique
5. Code	`ansible-lint --profile=production` passe, FQCN partout	`command:` partout, `shell:` non sécurisé
6. Permissions	Pas de `become: true` au niveau rôle ; pas de modules root inutiles	`become: true` global, élévation cachée
7. Dépendances	Liste explicite de collections requises, versions pinnées	`dependencies:` floues, dépendances cachées

# Vérifications express
git log --oneline -10 .                  # activité récente
ls molecule/                              # présence tests
ansible-lint --profile=production .       # qualité code
grep -rn "become: true\|command:\|shell:" tasks/  # élévations / shell

Sécurité non négociable :

Pas d'install sans audit, un rôle malveillant qui tourne en root sur 50 serveurs = compromission totale. Le coût d'audit (10 min) est négligeable face au coût d'incident.
Préférer un rôle officiel ansible-collections/* ou un mainteneur reconnu (geerlingguy, robertdebock, etc.) à un fork inconnu.
Forker + auditer + maintenir plutôt que de dépendre d'un rôle abandonné, meilleure traçabilité.
Pinning version exact (version: 1.2.3, pas >=1.0.0), évite qu'une mise à jour silencieuse change le comportement sans review.
Lire les tasks/main.yml et meta/main.yml AVANT install, vérifier qu'aucune action étrange (uri: vers un endpoint suspect, command: curl ... | bash, base64 décodé en script).

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

Pratiquer dans le lab

Cette page a un lab d'accompagnement : labs/galaxy/auditer-role-existant/ dans stephrobert/ansible-training.

Le lab fournit un AUDIT_CHECKLIST.md complet avec 25+ checkpoints. 8 tests structure validés.

cd ~/Projets/ansible-training/labs/galaxy/auditer-role-existant/

cat AUDIT_CHECKLIST.md
pytest -v challenge/tests/             # 8 tests

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.

Prochaines étapes

Versionner et publier Si vous publiez vos rôles, savoir comment les autres vont les auditer

Trouver le bon module Audit équivalent pour les modules / collections

Installer des rôles Galaxy Le format requirements.yml + signatures cryptographiques

ansible-lint production Vérifier automatiquement les axes 2 et 3 (qualité + sécurité)