Module user Ansible : créer, modifier, supprimer des utilisateurs

ansible.builtin.user: gère les utilisateurs Linux : création, modification (shell, home, groupes), hashage de password, suppression. C’est le module n°1 pour l’onboarding de membres d’équipe et le provisioning de comptes applicatifs.

Options critiques RHCE 2026 : name:, state:, shell:, groups: + append:, password: (avec password_hash), uid:, comment:, remove: sur state: absent.

# Création d'un utilisateur applicatif (mot de passe hashé via vault)
- ansible.builtin.user:
    name: alice
    shell: /bin/bash
    groups:
      - wheel        # accès sudo
      - docker
    append: true     # AJOUTE aux groupes existants — sans append: ÉCRASE
    state: present
    password: "{{ vault_alice_password_hash }}"   # déjà hashé via vault
    update_password: on_create   # ne réécrit pas si l'utilisateur existe déjà
    create_home: true
    home: /home/alice
    comment: "Alice — DevOps"
  no_log: true       # empêche le hash d'apparaître en debug
  become: true

# Compte de service avec UID fixé (cohérence multi-hôtes)
- ansible.builtin.user:
    name: myapp
    uid: 1500            # UID stable entre les hôtes (NFS, fichiers partagés)
    system: true         # compte système (UID < 1000 sur RHEL)
    shell: /sbin/nologin # pas de login interactif
    create_home: false   # pas de home pour un compte technique
    state: present
  become: true

# Suppression complète (home + cron + mail)
- ansible.builtin.user:
    name: alice
    state: absent
    remove: true        # supprime aussi /home/alice et /var/spool/mail/alice
    force: true
  become: true

Sécurité non négociable :

Mot de passe pré-hashé via password_hash('sha512') ou stocké hashé dans Vault — JAMAIS de mot de passe en clair dans un playbook ou un inventory.
no_log: true sur toute tâche user: qui touche à password: — sinon Ansible logge la valeur en -v ou en cas d’échec, et le hash atterrit dans Splunk/ELK.
update_password: on_create pour ne pas réécraser un mot de passe existant à chaque run (sinon changed=true éternel + risque de revert d’un changement manuel légitime).
groups: SANS append: true = vous écrasez les groupes secondaires existants. Toujours append: true sauf si vous voulez explicitement remplacer.
Compte de service : system: true + shell: /sbin/nologin + create_home: false — pas de login interactif possible.
remove: true + force: true sur state: absent pour ne pas laisser des fichiers orphelins (home, mail, cron).

Ce que vous allez apprendre

Créer un utilisateur avec home, shell, groupes secondaires.
Hasher un password avec password_hash('sha512') pour le stockage idempotent.
Distinguer groups: + append: true (ajouter) vs groups: seul (remplacer — danger).
Forcer un uid: précis pour les comptes système / applicatifs (cohérence multi-hôtes).
Supprimer un compte avec remove: true (qui supprime aussi le home).

Prérequis

Avoir become: true configuré (création d’user nécessite root).
Avoir lu Module group — créer le groupe avant l’user qui le référence.

Création basique

- name: Creer alice
  ansible.builtin.user:
    name: alice
    comment: "Alice — admin RHCE 2026"
    shell: /bin/bash
    state: present

À la première exécution : useradd alice -c "Alice — admin RHCE 2026" -s /bin/bash est lancé. Ansible crée le home /home/alice/, génère un groupe primaire alice (UID = GID = premier libre ≥ 1000).

Idempotence : 2e run → changed=0. Ansible vérifie chaque attribut et n’agit que sur ce qui diffère.

Groupes secondaires : la règle `append: true`

Le piège n°1 du module user: est l’oubli de append: true lors de la modification.

# ❌ DANGER : remplace TOUS les groupes secondaires
- ansible.builtin.user:
    name: bob
    groups: [video]

# ✅ CORRECT : ajoute video sans toucher aux autres
- ansible.builtin.user:
    name: bob
    groups: [video]
    append: true

Sans append: true, si bob était dans [wheel, docker, sudo], après la 1ère tâche il est uniquement dans video. Bob a perdu wheel et docker sans alerte.

Règle : pour modifier les groupes d’un utilisateur existant, toujours append: true. La seule exception : remise à zéro intentionnelle des droits (offboarding).

Password hashé (et l’idempotence)

# Pattern naif (casse l idempotence)
- ansible.builtin.user:
    name: charlie
    password: "{{ 'PasswordEnClair' | password_hash('sha512') }}"

Sans salt fixe, password_hash('sha512') génère un hash différent à chaque run → tâche toujours changed.

Pattern propre (RHCE) : générer le hash une fois et le stocker dans host_vars/ (avec Vault).

# host_vars/db1.lab.yml (chiffre avec ansible-vault)
charlie_password_hash: "$6$randomsalt$hashvalue..."

# Dans le playbook :
- ansible.builtin.user:
    name: charlie
    password: "{{ charlie_password_hash }}"

Pour générer le hash en CLI :

mkpasswd -m sha-512 'PasswordEnClair'
# ou
python3 -c "import crypt; print(crypt.crypt('PasswordEnClair', crypt.mksalt(crypt.METHOD_SHA512)))"

update_password: on_create complète le pattern : ne touche au password que si l’user est nouvellement créé, pas s’il existe déjà.

UID forcé pour les comptes système

- name: Compte applicatif deploy avec UID 2000
  ansible.builtin.user:
    name: deploy
    uid: 2000
    group: deploy
    home: /opt/deploy
    create_home: true
    shell: /bin/bash

Pourquoi forcer l’UID ? Sur 50 hôtes, useradd auto-attribue le premier UID libre. Si web1 a deploy=1001 et web2 a deploy=1002, un fichier monté en NFS appartenant à 1001 sera inaccessible par deploy sur web2.

uid: force la cohérence. Si l’UID est déjà pris par un autre user, la tâche failed (pas de collision silencieuse).

Convention RHEL :

UID < 1000 : comptes système (system: true).
UID 1000-2000 : utilisateurs humains.
UID 2000+ : comptes applicatifs (réservé par convention).

Modification d’un user existant

Tous les attributs sauf name peuvent être modifiés :

- name: Changer le shell de alice
  ansible.builtin.user:
    name: alice
    shell: /bin/zsh

- name: Modifier le commentaire
  ansible.builtin.user:
    name: alice
    comment: "Alice — promue lead admin"

Ansible exécute usermod -s /bin/zsh alice et usermod -c "..." alice. Idempotent : 2e run → ok si valeurs identiques.

Suppression : avec ou sans le home

# Suppression sans nettoyer le home (defaut)
- ansible.builtin.user:
    name: charlie
    state: absent
    remove: false

# Suppression complete (home + spool mail)
- ansible.builtin.user:
    name: charlie
    state: absent
    remove: true

remove: false (défaut) = userdel charlie → home /home/charlie/ conservé. Pattern d’audit-friendly : on peut récupérer les fichiers du compte supprimé.

remove: true = userdel -r charlie → home + mail supprimés. Pour le nettoyage final après archivage des données.

Pièges courants

Symptôme	Cause	Fix
Bob a perdu ses droits sudo après modif	Oubli de `append: true` sur `groups:`	Toujours `append: true` en modification
`changed=1` à chaque run sur le password	`password_hash` sans salt fixe	Stocker le hash dans `host_vars/` (Vault)
Conflit d’UID entre hôtes	Pas de `uid:` forcé	Forcer `uid:` sur les comptes applicatifs
Home reste après `state: absent`	`remove: false` (défaut)	Ajouter `remove: true` pour nettoyer
Tâche failed “uid already exists”	UID déjà utilisé par un autre user	Choisir un UID libre, ou résoudre le conflit

À retenir

name: est la clé d’identification — ne jamais modifier.
groups: + append: true pour ajouter, pas remplacer.
password: = hash SHA-512, idéalement stocké dans host_vars/ (Vault).
uid: forcé sur les comptes système / applicatifs (cohérence multi-hôtes).
remove: true sur state: absent pour supprimer le home.
Création de groupe AVANT création de l’user qui le référence.

Pratiquer dans le lab

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

Challenge — sur db1.lab :

Créer un groupe rhce-team.
Créer alice (admin, dans wheel), bob (UID 2001), deploy (UID 2000, home /opt/deploy/).

Validation pytest+testinfra :

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

6 tests vérifient les attributs (UID, groupes, home, shell).

Prochaines étapes

Module group Créer les groupes nécessaires AVANT d'y ajouter des utilisateurs

Module authorized_key Provisionner les clés SSH des utilisateurs créés

Module sudoers Donner les droits sudo de manière granulaire et idempotente

Filtres Jinja2 avancés password_hash et autres filtres pour gérer les secrets correctement