Sécurité Ansible : protéger vos playbooks et votre infrastructure

Un playbook Ansible mal sécurisé peut exposer des secrets à l’ensemble de votre équipe, propager une mauvaise configuration à des centaines de serveurs, ou ouvrir une porte dérobée via une collection compromise. Ansible amplifie tout : les bonnes pratiques comme les mauvaises.

Ce guide centralise les principes de sécurité à appliquer dans vos projets Ansible. Il complète les guides spécifiques comme Ansible Vault en offrant une vue d’ensemble.

Gestion des secrets

Les playbooks manipulent des données sensibles : mots de passe, clés API, certificats, tokens. Ces secrets ne doivent jamais apparaître en clair.

Les anti-patterns à éviter

Anti-pattern	Risque	Solution
Mot de passe en clair dans une variable	Exposition dans Git, logs, historique	Ansible Vault
vault_password_file commité	Tout le monde peut déchiffrer	.gitignore + variable d’environnement
Secret affiché dans les logs	Visibilité dans CI/CD, AWX	no_log: true sur les tâches
Un seul mot de passe Vault	Compromission totale si fuite	Vault IDs par environnement
Credentials dans --extra-vars	Visible dans ps aux	Fichier chiffré ou variable d’environnement

Utiliser no_log correctement

- name: Configurer la connexion base de données
  ansible.builtin.template:
    src: db.conf.j2
    dest: /etc/app/db.conf
    mode: "0600"
  vars:
    db_password: "{{ vault_db_password }}"
  no_log: true  # Masque les variables dans les logs

Attention

no_log: true masque toute la sortie de la tâche, y compris les erreurs. Utilisez-le uniquement sur les tâches manipulant des secrets, pas partout.

Intégration avec des gestionnaires de secrets externes

Pour les environnements critiques, Ansible Vault peut être complété par des solutions externes :

Solution	Usage	Lookup Ansible
HashiCorp Vault	Secrets dynamiques, rotation	community.hashi_vault.vault_read
AWS Secrets Manager	Environnements AWS	amazon.aws.secretsmanager_secret
Azure Key Vault	Environnements Azure	azure.azcollection.azure_keyvault_secret
CyberArk	Entreprise, compliance	cyberark.conjur.conjur_variable

Pour approfondir : Gestion des secrets

Principe de moindre privilège

Le principe de moindre privilège s’applique à plusieurs niveaux avec Ansible.

Sur le control node

L’utilisateur qui exécute Ansible n’a pas besoin d’être root :

# Créer un utilisateur dédié
sudo useradd -m -s /bin/bash ansible
sudo mkdir -p /home/ansible/.ssh
sudo chown -R ansible:ansible /home/ansible

Protégez les fichiers sensibles :

chmod 600 ~/.ansible/vault_password
chmod 600 inventory/group_vars/*/vault.yml
chmod 700 ~/.ssh

Sur les managed nodes

Limitez l’usage de become aux tâches qui en ont réellement besoin :

# ❌ Mauvais : become global
- hosts: webservers
  become: true  # Tout le playbook en root
  tasks:
    - name: Installer nginx
      ansible.builtin.apt:
        name: nginx

    - name: Copier la config applicative
      ansible.builtin.template:
        src: app.conf.j2
        dest: /home/appuser/app.conf
        owner: appuser

# ✅ Mieux : become ciblé
- hosts: webservers
  tasks:
    - name: Installer nginx
      ansible.builtin.apt:
        name: nginx
      become: true  # Nécessaire pour apt

    - name: Copier la config applicative
      ansible.builtin.template:
        src: app.conf.j2
        dest: /home/appuser/app.conf
        owner: appuser
      # Pas de become si l'utilisateur Ansible a les droits

Credentials par environnement

Séparez les credentials entre environnements :

inventory/
├── dev/
│   ├── hosts.yml
│   └── group_vars/
│       └── all/
│           └── vault.yml      # Credentials dev
├── staging/
│   └── ...
└── prod/
    └── group_vars/
        └── all/
            └── vault.yml      # Credentials prod (accès restreint)

Supply chain des collections et rôles

Les attaques supply chain concernent aussi Ansible. Une collection ou un rôle compromis peut exécuter du code arbitraire sur votre infrastructure.

Vérifier la provenance

Avant d’utiliser une collection ou un rôle tiers :

1. Vérifiez le namespace : préférez les namespaces officiels (ansible.*, community.*, éditeurs connus)
2. Consultez le code source : lisez au moins les tâches principales
3. Vérifiez la maintenance : commits récents, issues traitées
4. Utilisez OpenSSF Scorecard : évaluez la posture sécurité du dépôt

Épingler les versions

Ne laissez jamais Ansible installer la “dernière version” :

requirements.yml

collections:
  - name: community.general
    version: "8.1.0"  # ✅ Version épinglée
  - name: amazon.aws
    version: ">=7.0.0,<8.0.0"  # ✅ Plage contrôlée

roles:
  - name: geerlingguy.docker
    version: "6.2.0"  # ✅ Version épinglée

Miroir privé pour les environnements sensibles

Pour les environnements critiques, utilisez un miroir interne :

• Automation Hub (Red Hat) : collections certifiées et validées
• Dépôt Git interne : fork des collections utilisées
• Proxy Artifactory ou Nexus : cache avec contrôle d’accès

Modules à risque

Certains modules Ansible présentent des risques de sécurité accrus.

shell, command, raw : injection de commandes

Ces modules exécutent des commandes shell. Si les variables ne sont pas validées, une injection est possible :

# ❌ Dangereux : injection possible
- name: Supprimer un fichier
  ansible.builtin.shell: "rm -rf {{ user_input }}"
  # Si user_input = "; rm -rf /" → catastrophe

# ✅ Préférer un module spécialisé
- name: Supprimer un fichier
  ansible.builtin.file:
    path: "{{ validated_path }}"
    state: absent

Quand utiliser les modules shell ?

Situation	Recommandation
Tâche réalisable avec un module	Utiliser le module (idempotent, sécurisé)
Script complexe existant	Copier le script, exécuter avec script
Commande ponctuelle simple	command avec validation des entrées
Pipes, redirections nécessaires	shell avec no_log si données sensibles

Valider les entrées

- name: Valider le nom d'utilisateur
  ansible.builtin.assert:
    that:
      - username is match('^[a-z][a-z0-9_-]{2,31}$')
    fail_msg: "Nom d'utilisateur invalide : {{ username }}"

- name: Créer l'utilisateur (après validation)
  ansible.builtin.user:
    name: "{{ username }}"
    state: present

Validation du code

Avant d’exécuter un playbook en production, validez-le.

Outils de validation

Outil	Usage	Commande
Syntaxe YAML	Erreurs de parsing	ansible-playbook --syntax-check
ansible-lint	Bonnes pratiques, sécurité	ansible-lint playbook.yml
yamllint	Style YAML strict	yamllint .
Dry-run	Voir les changements	ansible-playbook --check --diff

Intégration CI/CD

.gitlab-ci.yml

lint:
  stage: test
  script:
    - pip install ansible-lint yamllint
    - yamllint .
    - ansible-lint playbook.yml
    - ansible-playbook --syntax-check playbook.yml

test:
  stage: test
  script:
    - pip install molecule molecule-docker
    - molecule test

Molecule pour les tests de rôles

Molecule permet de tester vos rôles dans des conteneurs isolés :

# Initialiser Molecule dans un rôle
molecule init scenario -d docker

# Exécuter les tests
molecule test

Sécurisation des connexions

Clés SSH

• Utilisez des clés SSH, jamais de mots de passe
• Préférez les clés avec passphrase + ssh-agent
• Une clé par environnement (dev/staging/prod)
• Rotation régulière des clés

host_key_checking

Ne désactivez jamais host_key_checking en production :

# ansible.cfg
[defaults]
# ❌ Dangereux en production : vulnérable aux attaques MITM
# host_key_checking = False

# ✅ Désactiver uniquement pour les environnements éphémères
# Utiliser une variable d'environnement si nécessaire
# ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook ...

Connexion via bastion

Pour les environnements isolés :

# ansible.cfg ou inventory
[ssh_connection]
ssh_args = -o ProxyJump=bastion.example.com

Traçabilité et audit

Activer les logs

# ansible.cfg
[defaults]
log_path = /var/log/ansible/ansible.log

Protégez le fichier de log :

sudo mkdir -p /var/log/ansible
sudo chown ansible:ansible /var/log/ansible
sudo chmod 750 /var/log/ansible

Callback plugins pour l’audit

# ansible.cfg
[defaults]
callback_whitelist = json, profile_tasks

AWX/AAP pour la centralisation

Pour les équipes, AWX ↗ ou Ansible Automation Platform offrent :

• RBAC : contrôle d’accès par rôle
• Audit trail : qui a lancé quoi, quand
• Approbations : workflow de validation avant exécution
• Credentials vault : stockage centralisé et sécurisé

Configuration sécurisée

Paramètres critiques dans ansible.cfg

[defaults]
# Logs pour audit
log_path = /var/log/ansible/ansible.log

# Timeout raisonnable
timeout = 30

# Ne pas afficher les mots de passe dans les diff
display_args_to_stdout = False
display_skipped_hosts = True

# Désactiver les warnings obsolètes en prod (mais les traiter !)
# deprecation_warnings = False

[ssh_connection]
# Réutiliser les connexions SSH
pipelining = True

# Timeout de connexion
timeout = 10

[privilege_escalation]
# Ne pas activer become par défaut
become = False

Hiérarchie des fichiers ansible.cfg

Attention : Ansible charge le premier ansible.cfg trouvé dans cet ordre :

1. $ANSIBLE_CONFIG (variable d’environnement)
2. ./ansible.cfg (répertoire courant)
3. ~/.ansible.cfg (home de l’utilisateur)
4. /etc/ansible/ansible.cfg (système)

Risque de sécurité

Un ansible.cfg malveillant dans un dépôt cloné peut modifier le comportement d’Ansible (désactiver les vérifications, exfiltrer des données via callback). Vérifiez toujours les fichiers ansible.cfg des projets tiers.

Checklist sécurité

Avant de déployer en production :

• Secrets chiffrés avec Vault (pas de credentials en clair)
• no_log: true sur les tâches manipulant des secrets
• become limité aux tâches qui en ont besoin
• Versions des collections/rôles épinglées
• ansible-lint passé sans erreur critique
• Dry-run (--check --diff) exécuté et vérifié
• Clés SSH différentes par environnement
• Logs activés pour l’audit

À retenir

1. Les secrets ne doivent jamais apparaître en clair — Vault, no_log, et gestionnaires externes.

2. Moindre privilège partout — become ciblé, credentials séparés par environnement.

3. La supply chain est un risque — vérifiez, épinglez, auditez les collections et rôles tiers.

4. Validez avant d’exécuter — ansible-lint, —check, Molecule.

5. Tracez tout — logs, AWX, historique Git pour l’audit et la conformité.

Contrôle de connaissances

Maintenez vos compétences à jour en répondant au quiz suivant sur la sécurité Ansible.

Pourquoi ce contrôle ?

Cet contrôle va vous permettre de valider vos connaissances sur le sujet abordé dans le guide. Il comporte des QCM, des questions vrai/faux et des réponses ouvertes à un mot.

🕒 Le chronomètre commence dès que vous cliquez sur Démarrer le test. Vous devrez terminer l’examen avant la fin du temps imparti.

🎯 Pour réussir, vous devez obtenir au moins 80% de bonnes réponses.

💡 Je ne fournis pas directement les réponses aux questions. Cependant, si certaines sont complexes, des pistes d’explication pourront être proposées dans le guide ou après l’examen.

Bonne chance ! 🚀

Démarrer le test

Temps restant :

Liens utiles

• Ansible Vault — Chiffrement des secrets
• Principes de sécurité — Fondamentaux à connaître
• Moindre privilège — Limiter les droits
• Supply chain — Sécuriser les dépendances
• Gestion des secrets — Bonnes pratiques générales