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.

Défaut surprenant : nopassword: true

Depuis community.general 11.0, le défaut de nopassword: est true (sudo sans password) ! Pour exiger un password, explicitement mettre nopassword: false. Surprise classique sur les versions récentes.

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

La première ligne est d'une autre nature que les trois suivantes : elle décrit un incident bloquant qui exige une console physique, là où les autres se corrigent en rejouant le playbook. Les deux du milieu sont des surprises de configuration, le défaut nopassword: true et les permissions que sudo exige, et la dernière un simple oubli d'installation de la collection.

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

Glissez pour voir

Audit et bonnes pratiques

Une règle sudo se relit bien plus souvent qu'elle ne s'écrit, en revue de sécurité ou après un incident. Les quatre points ci-dessous servent cette relecture : un fichier par règle pour que le listing du répertoire donne la cartographie des droits, un nom préfixé par l'équipe pour trier, et deux niveaux de journalisation, l'invocation seule ou la session complète pour les comptes les plus exposés.

• /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.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

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

Lab pratique

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 et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/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. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

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.

×

📖 Voir la documentation →