Module sudoers Ansible : gérer les droits sudo de façon sûre

community.general.sudoers: génère des fichiers dans /etc/sudoers.d/ avec validation visudo -cf automatique. C’est le module de référence pour les droits sudo en Ansible — bien plus sûr qu’un lineinfile: sur /etc/sudoers (un fichier mal formé verrouille sudo pour tous les utilisateurs).

Ce module appartient à la collection community.general (pas builtin). Sur Ansible Core 2.20, l’installer via ansible-galaxy collection install community.general.

Options principales : name: (filename dans /etc/sudoers.d/), user: ou group:, commands:, nopassword:, state:, runas:, validation:.

# Compte ansible : NOPASSWD complet (lab, CI/CD)
- community.general.sudoers:
    name: ansible          # crée /etc/sudoers.d/ansible (mode 0440)
    user: ansible
    nopassword: true
    commands: ALL
    state: present
  become: true

# Moindre privilège : une commande précise pour un service
- community.general.sudoers:
    name: deploy-restart-nginx
    user: deploy
    nopassword: true
    commands:
      - /usr/bin/systemctl restart nginx
      - /usr/bin/systemctl reload nginx
    state: present
  become: true

# Membres du groupe ops avec password requis (compromise sudo + auth)
- community.general.sudoers:
    name: ops-team
    group: ops
    nopassword: false       # demande le mot de passe → bloque les bots compromis
    commands: ALL
    state: present
  become: true

Sécurité non négociable :

JAMAIS lineinfile: sur /etc/sudoers — une faute de syntaxe verrouille sudo pour tous les utilisateurs, y compris root via su (sans console root, vous êtes hors du serveur). Le module sudoers: valide automatiquement avec visudo -cf avant écriture.
Fichiers dans /etc/sudoers.d/<nom> mode 0440 root:root — appliqué automatiquement par le module, mais sachez-le pour ne jamais le contourner.
Moindre privilège : préférer commands: ciblées plutôt que commands: ALL. Un compte de déploiement n’a pas besoin de ALL — juste de redémarrer son service.
nopassword: true réservé aux comptes techniques (Ansible, CI/CD) sur des hôtes isolés réseau ; pour des humains, forcer la saisie du mot de passe.
Chemins absolus dans commands: (/usr/bin/systemctl) — un chemin relatif ouvre la voie à un PATH hijacking.
!command pour exclure (ex: commands: ALL, !/bin/su, !/usr/bin/passwd root) — durcissement classique.

Ce que vous allez apprendre

Pourquoi ne jamais modifier /etc/sudoers directement.
Créer une règle sudo simple avec validation automatique.
Limiter l’accès à des commandes précises (principe de moindre privilège).
Distinguer sudo avec password (défaut) de nopassword: true.
Cibler un groupe (préfixe % en syntaxe sudoers).
Forcer un runas: différent de root.

Prérequis

Avoir community.general installé : ansible-galaxy collection install community.general.
Comprendre la syntaxe sudoers de base (user host=(runas) commands).

Pourquoi pas `lineinfile:` sur `/etc/sudoers` ?

# ❌ TRES DANGEREUX
- ansible.builtin.lineinfile:
    path: /etc/sudoers
    line: "alice ALL=(ALL) NOPASSWD:ALL"

Risques :

Si la ligne est mal formée (typo, syntaxe non standard), /etc/sudoers devient invalide.
sudo refuse alors de fonctionner — personne ne peut élever ses droits.
Sur un serveur en production, vous êtes bloqué : impossible de revenir en arrière sans accès console physique ou IPMI.

Avec community.general.sudoers:, la validation visudo -cf %s est automatique et obligatoire — un fichier invalide n’est jamais déposé.

Création d’une règle simple

- name: Sudo complet pour alice (avec password)
  community.general.sudoers:
    name: lab-alice
    user: alice
    commands: ALL
    nopassword: false   # Defaut: true depuis community.general 11+ !
    state: present

Le module crée /etc/sudoers.d/lab-alice avec :

Permissions 0440 (lecture root uniquement + groupe root).
Validation visudo automatique avant le dépôt.
Contenu : alice ALL=(ALL) ALL (avec password requis).

Sudo sans password (`nopassword: true`)

- name: Compte CI sans password
  community.general.sudoers:
    name: lab-ci-bot
    user: ci-bot
    commands: ALL
    nopassword: true
    state: present

Génère : ci-bot ALL=(ALL) NOPASSWD:ALL.

Cas légitimes :

Compte ansible sur un managed node (NOPASSWD pour tous les modules).
Compte CI/CD qui doit lancer des commandes sans interaction.

Cas dangereux : utilisateurs humains — un attaquant qui prend le compte a root immédiatement. À éviter sauf raison technique précise.

Moindre privilège : limiter aux commandes nécessaires

- name: Alice peut redemarrer chronyd uniquement
  community.general.sudoers:
    name: lab-alice-chronyd
    user: alice
    commands:
      - /usr/bin/systemctl restart chronyd
      - /usr/bin/systemctl status chronyd
    nopassword: true
    state: present

Alice peut uniquement lancer ces 2 commandes en sudo. sudo systemctl restart sshd → refusé. C’est le pattern moindre privilège standard.

Combiné avec un user dédié + clés SSH restreintes (authorized_key), un développeur peut uniquement redémarrer son service sans accès root complet.

Règles sur un groupe (préfixe `%`)

- name: Tous les membres de ops-team ont sudo
  community.general.sudoers:
    name: lab-ops-team
    group: ops-team   # Au lieu de "user:"
    commands: ALL
    state: present

Génère : %ops-team ALL=(ALL) ALL. Le préfixe % désigne un groupe en syntaxe sudoers.

Avantage : ajouter un nouveau membre = usermod -aG ops-team carl → automatiquement sudoer. Pas besoin de modifier le fichier sudoers.

`runas:` (exécuter en tant que…)

Par défaut, sudo exécute en tant que root. runas: force un autre utilisateur cible.

- name: Alice peut runner comme deploy uniquement
  community.general.sudoers:
    name: lab-alice-as-deploy
    user: alice
    runas: deploy
    commands: /opt/myapp/bin/deploy.sh
    nopassword: true
    state: present

Génère : alice ALL=(deploy) NOPASSWD:/opt/myapp/bin/deploy.sh.

Alice peut faire sudo -u deploy /opt/myapp/bin/deploy.sh — mais pas sudo /opt/myapp/bin/deploy.sh (qui tenterait root → refusé).

Cas d’usage : un opérateur peut redémarrer une app sous le user applicatif sans escalade root.

Suppression

- name: Revoquer les droits sudo de bob
  community.general.sudoers:
    name: lab-bob
    state: absent

Le fichier /etc/sudoers.d/lab-bob est supprimé. Bob n’a plus de droits sudo (issus de cette règle — d’autres règles dans /etc/sudoers.d/* ne sont pas affectées).

Le piège : `validation: absent`

# ❌ DANGER
- community.general.sudoers:
    name: lab-broken
    user: alice
    commands: "INVALID SYNTAX !@#$"
    validation: absent   # Desactive visudo -cf

Avec validation: absent, le module ne valide pas la syntaxe. Le fichier est déposé tel quel. Si la syntaxe est invalide, sudo se casse globalement (refuse de lire /etc/sudoers.d/*).

Règle absolue : ne jamais désactiver validation:. La validation est gratuite (quelques ms) et empêche des incidents critiques.

Pièges courants

Symptôme	Cause	Fix
Sudo cassé partout après deploy	`lineinfile:` sur `/etc/sudoers` ou `validation: absent`	Toujours `community.general.sudoers:` avec validation
Tous les sudoers sont `NOPASSWD:`	Défaut `nopassword: true` depuis 11.0	Explicite `nopassword: false` quand password attendu
Permissions du fichier `0644` → sudo refuse	`community.general.sudoers:` pose 0440 automatiquement	Si fichier corrompu, supprimer et recréer via le module
`no module named community.general.sudoers`	Collection non installée	`ansible-galaxy collection install community.general`

Audit et bonnes pratiques

/etc/sudoers.d/ vs /etc/sudoers : isoler chaque règle dans un fichier dédié facilite l’audit, le rollback et la revue.
Logs sudo : journalctl -u sudo (ou /var/log/secure sur RHEL) tracent toutes les invocations.
Audit complet : Defaults log_input,log_output dans un fichier /etc/sudoers.d/audit pour logger les sessions complètes.
Convention naming : préfixer le name: par le rôle ou l’équipe (hr-team-readonly, ops-team-full) pour faciliter le tri.

À retenir

Module community.general.sudoers: (pas builtin — collection requise).
Validation visudo -cf automatique — toujours laisser activée.
Défaut surprenant : nopassword: true depuis community.general 11.
Permissions 0440 posées automatiquement.
commands: pour le moindre privilège (commandes spécifiques uniquement).
group: + préfixe % pour des règles sur un groupe.
runas: pour exécuter en tant qu’un autre user (pas root par défaut).
Ne jamais modifier /etc/sudoers directement — toujours /etc/sudoers.d/*.

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/modules-utilisateurs/sudoers/ dans stephrobert/ansible-training.

Challenge — sur db1.lab :

Créer 3 règles : alice (sudo avec password), ops-team (sudo NOPASSWD), alice can run as deploy (commande spécifique).
Vérifier la validation globale visudo -cf /etc/sudoers.

Validation pytest+testinfra :

ansible-playbook solution.yml
pytest -v labs/modules-utilisateurs/sudoers/challenge/tests/

7 tests vérifient permissions, contenu de chaque règle, et validation globale.

Prochaines étapes

Module user Créer les utilisateurs qui auront ces droits sudo

Module group Créer des groupes pour des règles sudo collectives (préfixe %)

Module authorized_key Compléter les droits sudo par des clés SSH restreintes

Pivot Modules Ansible Vue d'ensemble : modules builtin, posix, community.general