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

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
- name: Ajuster sudoers
  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
- name: Déclarer une règle sudo
  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/*.

Mettre en pratique

Une règle sudo mal formée ne se découvre qu'au moment où plus personne ne peut élever ses droits, console physique exceptée. Le lab vous fait déposer plusieurs règles dans /etc/sudoers.d/ sur une machine réelle : une avec mot de passe, une portant sur un groupe, une limitée à une commande précise avec runas:. La vérification relit ensuite les fichiers déposés sur la cible, contrôle les permissions 0440, le contenu de chaque règle, et la validation globale du fichier sudoers par visudo.

Module sudoers : gérer les droits sudo sans risque

$ dsoxlab run modules-utilisateurs-sudoers

Environnement : VM·Durée : ~50 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

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 modules-utilisateurs-sudoers
dsoxlab check modules-utilisateurs-sudoers

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Pour aller plus loin

Modules assert et fail : poser des préconditions explicites avant de toucher aux droits d'élévation.
Module stat : relire les permissions 0440 des fichiers déposés dans /etc/sudoers.d/.
Module SELinux : la couche de durcissement qui suit le moindre privilège, avec ses modes et ses booléens.