Créer un utilisateur DevOps - Sécurité, automatisation et bonnes pratiques

Créer un utilisateur en DevOps ne se résume pas à ouvrir une session de plus. Je pars toujours d’une règle simple : un compte doit correspondre à une tâche précise, avec le minimum de droits nécessaire pour la remplir. La logique derrière create user en DevOps est donc surtout une question de sécurité, d’automatisation et de maintenance, que ce soit sur un serveur Linux, dans un conteneur ou dans un pipeline d’infrastructure.

Définir le bon type de compte avant de le créer

Avant de créer quoi que ce soit, je regarde le rôle réel du compte. Un compte humain sert à se connecter, intervenir manuellement et laisser une trace claire. Un compte de service, lui, doit surtout exécuter une tâche répétable. Dans Kubernetes, un ServiceAccount donne une identité à un pod, pas à une personne, et cette nuance change complètement la manière de le sécuriser.

Pour un compte humain, j’ajoute presque toujours une authentification multifacteur, c’est-à-dire un second facteur en plus du mot de passe. Pour un compte de service, je coupe toute connexion interactive si elle n’a aucun sens. Pour un utilisateur de conteneur, je limite les droits au strict nécessaire dans l’image. Pour une identité cloud, je préfère souvent un rôle temporaire à un utilisateur permanent.

Créer un utilisateur local sous Linux pas à pas

Sur Linux, la différence entre adduser et useradd tient surtout à l’ergonomie et au niveau de contrôle. adduser guide davantage la création, alors que useradd est plus bas niveau et plus adapté aux scripts. Dans un parc hétérogène, je choisis la commande native de la distribution et je garde la logique explicite.

Pour un utilisateur humain, je veux généralement un répertoire personnel, un shell de connexion et un groupe d’administration adapté à la distribution. Pour un compte technique, je fais l’inverse : pas de shell interactif, un répertoire dédié seulement si nécessaire, et aucun privilège superflu.

# Debian / Ubuntu
sudo adduser alice
sudo usermod -aG sudo alice

# RHEL / Rocky / Fedora / CentOS
sudo useradd -m -s /bin/bash alice
sudo passwd alice
sudo usermod -aG wheel alice

Le point qui me semble le plus important ici, c’est l’option -a de usermod -aG : elle ajoute le groupe sans écraser les autres appartenances. Sans elle, on remplace souvent des groupes secondaires existants, et ce genre d’erreur est bête, discret et coûteux à corriger. Quand je crée un compte de service, je choisis aussi un shell de non-login adapté à la distribution, souvent /usr/sbin/nologin, pour empêcher les connexions interactives inutiles.

Le compte existe maintenant, mais sans politique de droits claire, on n’a rien gagné. Le vrai sujet devient alors la manière d’ouvrir les portes sans trop les élargir.

Donner les droits sans ouvrir trop large

Je préfère toujours une logique de moindre privilège. En pratique, cela veut dire trois choses : des groupes d’administration clairement nommés, des règles sudo limitées, et des modifications faites avec un outil qui vérifie la syntaxe avant d’écrire. Le cache d’authentification de sudo peut être pratique, mais il ne remplace jamais une vraie séparation des rôles.

Le piège du groupe docker

Je le dis franchement : ajouter un utilisateur au groupe docker revient souvent à lui donner un niveau de contrôle très proche de root sur l’hôte. Si le besoin est seulement d’exécuter des conteneurs, le mode rootless est généralement plus propre. Il lance Docker sans privilèges root, ce qui réduit la surface d’attaque et évite de faire dépendre toute la sécurité d’un groupe trop large.

Gérer sudo avec visudo

Quand je dois autoriser une action d’administration, je passe par visudo ou par un fichier dédié dans /etc/sudoers.d/. L’intérêt est simple : je garde une trace claire, et la syntaxe est contrôlée avant installation. C’est une petite discipline, mais elle évite des blocages stupides au moment où il faut intervenir vite sur une machine de production.

Quand la règle est stable, l’automatisation peut prendre le relais sans dériver. C’est là qu’Ansible devient vraiment utile.

Automatiser la création avec Ansible

Si la création d’un compte doit survivre à un rebuild de serveur, elle ne doit pas dépendre d’un clic manuel. Le module ansible.builtin.user décrit l’état attendu, puis le rejoue sans surprise. Autrement dit, il est idempotent : relancer le playbook ne crée pas de doublon, il remet juste la machine dans l’état voulu.

- name: Préparer les comptes d’exploitation
  hosts: app_servers
  become: true
  tasks:
    - name: Créer le groupe deploy
      ansible.builtin.group:
        name: deploy
        state: present

    - name: Créer l’utilisateur deployer
      ansible.builtin.user:
        name: deployer
        group: deploy
        groups: sudo
        append: true
        create_home: true
        shell: /bin/bash
        state: present

J’aime bien créer aussi le groupe avec ansible.builtin.group pour rendre la structure plus lisible. Si je dois gérer plusieurs comptes, je boucle dessus plutôt que de dupliquer les tâches. Pour les familles RHEL, je remplace souvent sudo par wheel, et je garde become: true parce que la création d’utilisateur reste une opération privilégiée.

- name: Créer plusieurs comptes
  ansible.builtin.user:
    name: "{{ item.name }}"
    groups: "{{ item.groups }}"
    append: true
    state: present
  loop:
    - { name: "alice", groups: "sudo" }
    - { name: "bob", groups: "deploy" }

Une fois ce socle automatisé, il reste les identités qui vivent au niveau des conteneurs et des plateformes, là où beaucoup d’équipes font encore des compromis un peu trop rapides.

Créer des identités techniques pour les conteneurs et le cloud

Tout ne vit pas sur un serveur classique. Une image Docker, un pod Kubernetes ou une intégration cloud a aussi besoin d’une identité propre. Quand une API backend, un worker ou une tâche qui pousse dans une base NoSQL accède à des ressources, je préfère un compte technique dédié plutôt qu’un compte humain détourné pour l’occasion.

Dans un Dockerfile

Dans une image, je crée un utilisateur dédié puis j’utilise USER pour que l’application ne tourne pas en root. Si le conteneur doit écrire quelque part, je prépare les permissions avant le passage au bon utilisateur. La syntaxe varie selon la base de l’image, mais l’idée reste la même : faire en sorte que le processus applicatif n’ait que les droits indispensables.

RUN useradd -r -m -s /usr/sbin/nologin appuser
USER appuser

Le mode rootless, c’est-à-dire l’exécution du démon Docker sans privilèges root, va dans le même sens. Quand l’environnement le permet, je le privilégie parce qu’il réduit la surface d’attaque et simplifie la logique de confiance.

Dans Kubernetes

Dans Kubernetes, je crée un ServiceAccount, puis j’attache les permissions avec RBAC, le contrôle d’accès fondé sur les rôles. Un pod de traitement ne doit obtenir que les verbes nécessaires sur les bonnes ressources. Pour un simple job de lecture, je limite aux opérations de lecture, point final. Une création rapide ressemble souvent à kubectl create serviceaccount api-reader, puis à une liaison de rôle adaptée au namespace.

Lire aussi : Installer Docker proprement - Le guide complet pour chaque OS

Dans le cloud

Dans le cloud, je réserve les identités permanentes aux cas qui l’exigent vraiment. Sur AWS, par exemple, les bonnes pratiques actuelles poussent plutôt vers des identités fédérées et des rôles temporaires pour les humains. Un utilisateur IAM permanent reste utile dans certains scénarios précis, mais je le traite comme une exception, pas comme la règle. C’est plus propre à révoquer, plus simple à auditer et plus difficile à oublier.

Ces identités techniques sont souvent celles qui posent le plus de problèmes quand on les laisse vivre trop longtemps sans règle claire. Le dernier réflexe que je garde me sert surtout à éviter ça.

Les détails qui gardent un compte propre sur la durée

Si je devais résumer ma manière de faire, je dirais ceci : je donne un nom clair au compte, je définis un propriétaire, je limite les droits et je planifie sa fin de vie dès le départ. Pour un accès temporaire, je pose souvent une revue à J+30 plutôt que de laisser le compte flotter sans contrôle.

• Je sépare toujours compte humain et compte technique.
• Je documente le groupe principal, le shell, le répertoire et la méthode d’authentification.
• Je vérifie les appartenances après chaque changement pour m’assurer que usermod -aG n’a rien écrasé.
• Je retire les clés, les jetons et les accès associés dès que le besoin disparaît.
• Je supprime les comptes orphelins dès qu’un service n’existe plus.

Je préfère un compte simple à expliquer, facile à révoquer et impossible à confondre avec un autre rôle. C’est cette discipline qui rend la création d’utilisateur vraiment utile à long terme, pas seulement correcte le jour où on la tape.