Trouver le bon module Ansible : cartographie et sécurité supply chain

Quand vous abordez un nouveau besoin (gérer un load-balancer, parler à une API CRM, configurer un firewall exotique), la première question à se poser est : quel module utiliser ? Ansible propose 3000+ modules répartis sur des dizaines de collections — vous trouverez quasiment toujours quelqu’un qui a déjà packagé votre cas d’usage. Mais cette abondance a un revers : toutes les collections ne se valent pas. Certaines sont abandonnées, d’autres mal maintenues, et quelques-unes peuvent être compromises (typosquatting, takeover de package, dépendances malicieuses). Cette page donne la méthode pour trouver vite le bon module et les garde-fous sécurité.

Pressé ? Les 3 commandes pour trouver et vérifier un module

# 1. Lister tous les modules d'un thème (bash, python, k8s...)
ansible-doc -l | grep -i k8s

# 2. Doc + snippet YAML prêt à copier
ansible-doc -s kubernetes.core.k8s

# 3. Vérifier l'intégrité d'une collection installée (signatures GPG, checksums)
ansible-galaxy collection verify kubernetes.core

Garde-fou installation : toujours pinner dans requirements.yml (version: 5.0.0, jamais latest). La doc embarquée (ansible-doc) est votre seule source autorisée à l’examen RHCE — apprenez à la lire vite. La suite explique la méthode complète (formulation du besoin, évaluation qualité, supply chain).

Ce que vous allez apprendre

• Identifier rapidement le module adapté à un besoin via ansible-doc -l et Galaxy.
• Évaluer la qualité d’une collection avant de l’installer.
• Pinner les versions dans requirements.yml pour éviter les mises à jour silencieuses.
• Vérifier l’authenticité d’une collection avec ansible-galaxy collection verify.
• Reconnaître les patterns d’attaques supply chain (typosquatting, dépendances malicieuses).

Méthode pour trouver un module

Étape 1 — Définir le besoin précisément

Avant de chercher, formulez le besoin en un verbe + un objet :

Besoin formulé vague	Reformulation utile
« Gérer Docker »	« Démarrer un conteneur Docker avec une image et un volume »
« Configurer le firewall »	« Ouvrir le port 443/tcp dans la zone publique de firewalld »
« Parler à une API »	« Faire un POST JSON vers une API REST avec authentification Bearer »

Glissez pour voir

Plus le besoin est précis, plus il est facile de trouver le bon module — au lieu de feuilleter 300 modules Docker, vous cherchez docker_container.

Étape 2 — Chercher dans ansible-doc

ansible-doc -l | grep -i docker
ansible-doc -l | grep -i firewall
ansible-doc -l | grep -i mysql

ansible-doc -l liste tous les modules installés (collections présentes sur votre control node) avec leur description courte. Filtrer avec grep est l’approche la plus rapide.

$ ansible-doc -l | grep -i docker | head -5
community.docker.current_container_facts        Return facts about whether the module runs ...
community.docker.docker_compose_v2              Manage multi-container Docker applications ...
community.docker.docker_container               manage Docker containers
community.docker.docker_container_copy_into     Copy a file into a Docker container
community.docker.docker_container_exec          Execute command in a Docker container

Pour les modules non installés, naviguer sur galaxy.ansible.com ou docs.ansible.com.

Étape 3 — Lire la doc complète

Une fois un candidat identifié :

ansible-doc community.docker.docker_container

Repérer :

• Les paramètres requis (souvent name:, state:, image: pour Docker).
• Les paramètres avec defaults raisonnables (qu’on peut omettre).
• Les exemples en bas de doc — le copier-coller est souvent suffisant pour démarrer.
• La version mini Ansible requise (compatibilité avec votre ansible-core).

Étape 4 — Le snippet -s

ansible-doc -s community.docker.docker_container > /tmp/snippet.yml

Génère un YAML annoté prêt à coller dans votre playbook. Indispensable au RHCE pour gagner du temps.

Cartographie des collections principales

Collection	Périmètre	Maintenu par	Quand l’utiliser
ansible.builtin	Modules cœur livrés avec ansible-core	Red Hat	Toujours en premier — copy, file, dnf, apt, systemd, user, group, lineinfile
ansible.posix	Linux/POSIX bas niveau	Red Hat	firewalld, mount, sysctl, selinux, authorized_key
community.general	Catalogue générique très large	Communauté	sudoers, lvg, lvol, hostname, pamd, nmcli — quand builtin/posix ne suffisent pas
community.crypto	Cryptographie X.509	Communauté	Certificats SSL, clés OpenSSH, CSRs
community.docker	Docker / Docker Compose	Communauté	Conteneurs, images, networks, volumes Docker
community.libvirt	Virtualisation libvirt/KVM	Communauté	Inventaire dynamique KVM, gestion de VMs (lab inventaires/dynamique-kvm)
community.mysql / community.postgresql	Bases de données	Communauté	Users, databases, replication
community.hashi_vault	HashiCorp Vault / OpenBao	Communauté	Lookups de secrets, intégration Vault
kubernetes.core	Kubernetes natif	Red Hat	k8s module, helm, helm_repository
amazon.aws	AWS officielle	Red Hat	EC2, S3, RDS, IAM, VPC, Route53
azure.azcollection	Azure officielle	Microsoft	VMs, storage, AKS, identités managées
google.cloud	GCP officielle	Google	Compute, GKE, Cloud Storage
ansible.windows	Windows officielle	Red Hat	win_user, win_service, win_feature, win_chocolatey
community.windows	Windows extensions	Communauté	Compléments à ansible.windows
redhat.satellite	Red Hat Satellite	Red Hat	Hosts, content views, sync plans

Glissez pour voir

Règle pragmatique : commencer par ansible.builtin, descendre vers ansible.posix, puis community.general. Aller chercher une collection plus spécifique uniquement si nécessaire.

Évaluer une collection avant de l’installer

Toutes les collections Galaxy ne se valent pas. Avant d’ajouter community.<random> dans votre requirements.yml, vérifier :

Critères qualité

Critère	Comment vérifier	Pourquoi c’est important
Mainteneur	Page Galaxy → champ “Maintainer”	Les collections redhat.*, ansible.*, amazon.aws sont supportées Red Hat. Les community.* sont communautaires (qualité variable).
Activité	GitHub → date du dernier commit, issues ouvertes	Une collection sans commit depuis 18 mois est probablement abandonnée.
Tests CI	GitHub → workflow Actions ou GitLab CI	Pas de tests = pas de garantie d’idempotence ou de compatibilité versions.
Documentation	ansible-doc <module> complet ?	Une doc minimale signale souvent un développement rushé.
Téléchargements	Galaxy → compteur de downloads	Une collection à 50 downloads/an est rarement battle-tested.
Issues récurrentes	GitHub → issues fermées vs ouvertes	Beaucoup d’issues ouvertes sans réponse = mauvais signe.

Glissez pour voir

Le pinning de version dans requirements.yml

Mandatory pour éviter qu’une mise à jour casse votre pipeline ou introduise une vulnérabilité :

---
collections:
  - name: ansible.posix
    version: "1.6.2"        # ← version exacte (recommandé en prod)

  - name: community.general
    version: ">=8.0.0,<9.0.0"  # ← range mineur (acceptable)

  - name: amazon.aws
    version: "*"             # ← AVOID : version flottante

Argument : sans pinning, ansible-galaxy collection install -r requirements.yml --upgrade récupère la dernière version. Si un mainteneur publie une régression, votre pipeline casse silencieusement.

Sécurité — Attaques supply chain sur les collections

Les collections Ansible ne sont pas exemptes des attaques supply chain qui frappent npm, PyPI, Docker Hub. Connaître les patterns d’attaque permet de les éviter.

Pattern 1 — Typosquatting

Un attaquant publie une collection au nom proche d’une collection légitime, en espérant que vous fassiez une faute de frappe :

Collection légitime	Typosquats potentiels
community.general	community.generals, commmunity.general, community.genral
amazon.aws	amazon.awa, amazon-aws, amazons.aws
kubernetes.core	kubenetes.core, kubernets.core, kubernetes.cor

Glissez pour voir

Mitigation : copier-coller depuis Galaxy, ne jamais retaper un nom de collection. Vérifier le mainteneur officiel avant install.

Pattern 2 — Takeover de namespace

Un namespace abandonné par son mainteneur peut être récupéré par un attaquant qui publie ensuite une version malicieuse. Cas connu sur PyPI et npm — moins fréquent sur Galaxy mais possible.

Mitigation : préférer les namespaces maintenus par des organismes (redhat.*, ansible.*, amazon.aws, microsoft.azure) plutôt qu’un compte individuel. Vérifier l’activité du mainteneur.

Pattern 3 — Dépendances transitives malicieuses

Une collection peut dépendre d’autres collections, qui peuvent elles-mêmes dépendre de packages Python malveillants. La chaîne devient vite opaque.

Mitigation :

# Inspecter les dépendances avant install
ansible-galaxy collection install community.general --pre --no-deps
cat ~/.ansible/collections/ansible_collections/community/general/MANIFEST.json | jq '.collection_info.dependencies'

Si dependencies: contient une collection inconnue, investiguer.

Pattern 4 — Compromission d’une release

Le compte du mainteneur est piraté et une release malicieuse est publiée sous le nom légitime. Difficile à détecter sans signature.

Mitigation : depuis Galaxy 2024, les collections peuvent être signées avec GPG. Vérification :

ansible-galaxy collection verify community.general

Cette commande compare le digest local au digest publié sur Galaxy. Une divergence = collection altérée localement (ou release piratée).

Pattern 5 — Exécution de code dans setup.py

Les collections Galaxy ne devraient pas exécuter de code Python à l’installation, mais certaines (rares) le font via des hooks. Risque de payload caché.

Mitigation : préférer Automation Hub (Red Hat) ou un mirror privé validé par votre équipe sécurité, plutôt que Galaxy public.

Garde-fous opérationnels

Mirror privé (recommandé en entreprise)

# ansible.cfg
[galaxy]
server_list = corporate_hub

[galaxy_server.corporate_hub]
url = https://hub.corp.example.com/api/automation-hub/
token = <token>

Toute collection passe par votre mirror au lieu de Galaxy public. Le mirror est validé par l’équipe sécurité (scan, signature, allow-list).

Signature obligatoire dans requirements.yml

collections:
  - name: ansible.posix
    version: "1.6.2"
    signatures:
      - https://galaxy.ansible.com/api/v3/.../signatures/abc123

ansible-galaxy collection install -r requirements.yml vérifie la signature avant install. Si la signature ne correspond pas, l’install échoue.

Audit régulier

ansible-galaxy collection list > /tmp/collections.txt
# Comparer avec un état de référence connu (commit Git du fichier requirements.yml)
diff requirements.lock.yml /tmp/collections.txt

Un drift entre le lock et l’état réel signale un install non autorisé.

Scope restreint en CI

Le runner CI qui installe les collections doit avoir un scope minimal : pas d’accès réseau hors mirror privé, pas de credentials cloud, pas de write sur le repo. Si une collection malicieuse s’exécute, le blast radius est limité.

Pièges courants

Symptôme	Cause	Fix
Module installé mais couldn't resolve module/action	FQCN manquant	Toujours utiliser ansible.posix.firewalld: (pas juste firewalld:)
Mise à jour Galaxy casse le pipeline	Pas de pinning de version	version: "1.6.2" exact dans requirements.yml
Collection introuvable sur Galaxy	Récemment supprimée ou renommée	Chercher sur Automation Hub ou GitHub upstream
Collection community.X lente à installer	Dépendances Python lourdes	Vérifier MANIFEST.json → dependencies:
Module obsolète mais encore présent	Collection pas mise à jour	ansible-galaxy collection list --upgrade ou consulter le CHANGELOG

Glissez pour voir

À retenir

• Méthode pour trouver un module : ansible-doc -l | grep puis ansible-doc <fqcn> puis ansible-doc -s <fqcn>.
• 3 collections = 90 % des cas : ansible.builtin, ansible.posix, community.general.
• Pinning de version mandatory en requirements.yml — éviter les versions flottantes.
• Évaluer une collection : mainteneur, activité, tests CI, downloads, issues.
• Attaques supply chain : typosquatting, takeover, dépendances, releases compromises — connaître les patterns.
• Mitigation entreprise : mirror privé (Automation Hub), signatures, audit régulier, scope CI restreint.

Prochaines étapes

Pivot Modules Vue d'ensemble des 7 sous-sections de modules essentiels

Module package Le module agnostique multi-distro à connaître en priorité

raw, command, shell, script Quand aucun module dédié n'existe — à connaître pour ne pas en abuser

Sécurité Ansible Vault Pour les secrets, jamais en clair dans un repo — pattern complémentaire

×

📖 Voir la documentation →