Le fichier sudoers décide, très concrètement, qui peut exécuter quelle commande avec des privilèges élevés, sur quelle machine et sous quel compte cible. En DevOps, c’est l’un des leviers les plus sensibles, parce qu’il touche à la fois aux déploiements, aux redémarrages de services, aux scripts d’automatisation et à la capacité de corriger un incident sans ouvrir un accès root complet. Dans cet article, je vais montrer comment le lire, le modifier sans casser l’accès à sudo, et surtout comment écrire des règles utiles plutôt que trop larges.
Les points clés à retenir sur la gestion des privilèges sudo
- Le fichier de politique sudo décide qui peut lancer quelles commandes, en tant que quel utilisateur, et sur quels hôtes.
- La règle d’or est simple : modifier avec
visudo, jamais à l’aveugle. - Les fichiers dans
/etc/sudoers.d/sont souvent plus propres que les ajouts directs dans/etc/sudoers. - Les alias et les règles limitées par commande permettent de réduire fortement la surface d’attaque.
- L’ordre des lignes compte, et une règle trop large peut neutraliser une restriction plus précise.
Ce que contrôle vraiment /etc/sudoers
Je vois souvent une confusion de départ : beaucoup de gens pensent que ce fichier sert seulement à “donner sudo” à un utilisateur. En réalité, il gère une politique d’autorisation beaucoup plus fine. Il peut définir qui peut agir, sur quelle machine, avec quel compte cible, et pour quelles commandes. C’est précisément ce niveau de granularité qui le rend indispensable en DevOps.
Dans une équipe d’exploitation, je m’en sers pour séparer les usages. Un compte peut avoir le droit de redémarrer un service applicatif, sans pouvoir éditer la configuration du système. Un autre peut lancer un script de maintenance, sans avoir la main sur tout le reste. Cette logique limite les erreurs humaines et simplifie les audits, parce qu’on n’accorde pas plus de privilèges que nécessaire.
Le comportement ne se limite pas à l’autorisation pure. La politique sudo gère aussi l’authentification, certains paramètres d’environnement, la journalisation et des détails de fonctionnement qui deviennent visibles dès qu’un incident arrive. Autrement dit, ce n’est pas juste une liste d’utilisateurs autorisés, c’est une couche de contrôle d’accès. Pour écrire des règles propres, il faut ensuite comprendre la syntaxe ligne par ligne.
Lire la syntaxe sans se perdre
La forme d’une règle sudo paraît austère au début, mais elle suit une logique stable. Je la lis toujours de gauche à droite : utilisateur ou groupe, hôte, compte cible, puis commande. Quand on décompose ainsi, la plupart des règles deviennent lisibles d’un coup d’œil.
| Bloc | Rôle | Exemple | Point d’attention |
|---|---|---|---|
| Utilisateur ou groupe | Définit qui est concerné par la règle |
alice ou %deploy
|
Le préfixe % vise un groupe Unix |
| Hôte | Limite la règle à une machine ou un ensemble de machines |
ALL ou prod01
|
ALL est pratique, mais large |
| Runas | Précise sous quel utilisateur la commande s’exécute |
(root) ou (postgres)
|
Si on l’omit, l’exécution vise souvent root |
| Commande | Autorise un binaire ou un script précis | /bin/systemctl restart nginx |
Le chemin absolu compte |
| Tag | Ajoute un comportement comme le non-usage de mot de passe | NOPASSWD: |
À réserver aux cas justifiés |
Les alias qui évitent les lignes interminables
Quand une équipe grandit, les alias deviennent vite utiles. Ils servent à regrouper des utilisateurs, des hôtes, des comptes cible ou des commandes. C’est plus lisible, plus maintenable, et franchement plus agréable à auditer qu’une suite de règles copiées-collées.
User_Alias OPS = alice, bob
Cmnd_Alias WEB = /bin/systemctl restart nginx, /bin/systemctl reload nginx
OPS ALL=(root) WEBDans cet exemple, je donne à un groupe logique le droit d’agir uniquement sur le service web. La règle est courte, mais surtout elle reste compréhensible six mois plus tard. C’est exactement ce que je cherche dans une base d’administration : une politique claire, pas un labyrinthe. Une fois la syntaxe posée, la vraie question devient celle du changement sans risque.
Modifier sans prendre de risque
Je ne modifie jamais ce fichier avec un éditeur classique en me disant que “ça ira”. Le bon réflexe, c’est visudo. Cet outil verrouille le fichier pendant l’édition, vérifie la syntaxe avant d’enregistrer et évite de se retrouver avec une politique cassée après une simple faute de frappe. Sur une machine où sudo est le seul chemin vers l’administration, c’est une différence majeure.
- J’ouvre la politique avec
sudo visudopour le fichier principal. - Pour une règle isolée, j’utilise plutôt
sudo visudo -f /etc/sudoers.d/deploy. - Je valide ensuite la configuration avec
sudo visudo -c.
Le contrôle est particulièrement utile avec les fichiers de dépôt dans /etc/sudoers.d/. Selon les distributions, la directive d’inclusion apparaît sous la forme #includedir ou @includedir, mais l’idée reste la même : séparer les règles par fichier pour faciliter la maintenance. Je recommande des noms stables et ordonnés, par exemple 00-base, 10-deploy, 20-backup. L’ordre lexical compte, donc les zéros de tête évitent les surprises.
Ce que j’apprécie dans cette approche, c’est la capacité à versionner proprement les règles de privilèges. On peut relire un changement, le tester, puis le déployer comme n’importe quel autre artefact d’infrastructure. C’est beaucoup plus sain que d’empiler des exceptions dans le fichier central. À partir de là, on peut parler de construction de règles vraiment utiles en contexte DevOps.
Construire des règles utiles en DevOps
En DevOps, je privilégie presque toujours les règles orientées tâches plutôt que les accès génériques. L’objectif n’est pas de “laisser faire” un humain ou une machine, mais de rendre possible une action précise : déployer, redémarrer, lancer une sauvegarde, nettoyer un cache, relever un service. Cette différence change tout.
| Besoin | Règle conseillée | Pourquoi c’est préférable |
|---|---|---|
| Redémarrer un service |
systemctl restart ou reload sur un service précis |
On limite l’action à une opération d’exploitation nette |
| Lancer un déploiement | Un script wrapper unique avec chemin absolu | On évite d’ouvrir un shell complet ou une suite de commandes libres |
| Automatiser un pipeline CI/CD | Compte technique dédié avec permissions minimales | On sépare l’humain de l’automate et on simplifie l’audit |
| Maintenance d’astreinte | Groupe d’exploitation sur hôte ou environnement ciblé | On garde une gestion simple sans élargir à toute la flotte |
Lire aussi : Installer npm sur Debian - Le guide complet pour chaque contexte
Quand NOPASSWD a du sens
Je n’emploie NOPASSWD que quand la commande est prévisible, répétitive et non interactive. C’est souvent acceptable pour un script de déploiement, un redémarrage de service ou une tâche de sauvegarde bien encapsulée. En revanche, je l’évite pour des commandes trop larges, des shells, ou des outils qui ouvrent la porte à des détours trop faciles.
%ci ALL=(root) NOPASSWD: /usr/local/bin/deploy-appCe modèle fonctionne bien si /usr/local/bin/deploy-app est un vrai point d’entrée contrôlé, avec des paramètres fixes et un comportement connu. Si je dois laisser passer une suite de commandes, je préfère encore la déplacer dans un script maintenu dans le dépôt d’infra plutôt que d’éparpiller des privilèges sur plusieurs binaires. Le même principe s’applique aux commandes système : je vise le chemin exact, pas une idée vague de ce que l’utilisateur “pourra faire”. Cette discipline évite ensuite la plupart des erreurs classiques.
Les erreurs qui élargissent trop les privilèges
Le piège le plus courant, c’est l’accès trop généreux “pour que ça marche vite”. Le problème, c’est que ce type de raccourci finit presque toujours en dette de sécurité. Je préfère une règle un peu plus longue à écrire, mais qui reste défendable le jour où quelqu’un me demande pourquoi tel compte peut agir en root.
| Erreur fréquente | Pourquoi c’est risqué | Alternative plus saine |
|---|---|---|
ALL=(ALL) ALL |
Privilèges quasi complets, difficiles à justifier | Limiter à quelques commandes précises |
Interdire avec ! au lieu d’autoriser proprement |
Les règles négatives sont fragiles et moins lisibles | Construire une liste blanche explicite |
| Oublier le chemin absolu | Le moteur sudo valide des commandes, pas une intention | Pointer vers le binaire exact |
| Autoriser un shell ou un éditeur trop puissant | Les échappements de shell ouvrent des accès détournés | Utiliser un wrapper dédié et limité |
| Confondre ordre et spécificité | La dernière règle correspondante l’emporte | Structurer les fichiers et relire l’ordre de chargement |
Je fais aussi attention aux commandes composées de pipes, de redirections ou de chaînages &&. Sudo n’autorise pas une “phrase de shell” au sens libre du terme ; il autorise des commandes précises, et c’est une nuance importante. Si je veux un comportement composite, je le mets dans un script contrôlé plutôt que d’essayer de bricoler une exception dans la politique. Même chose pour certains outils dont le chemin change selon la distribution : je vérifie le binaire exact avant d’écrire la règle, pas après la panne.
Enfin, je surveille les logs. Une autorisation trop généreuse peut sembler pratique pendant une semaine, puis devenir invisible pendant six mois. Les traces d’exécution et de refus sont justement là pour rappeler où se situe la limite réelle. C’est ce regard d’exploitation qui me permet de garder une politique nette, exploitable et auditable dans la durée.
La base que je garde en production pour rester lisible et auditable
Quand je dois poser une base durable, je reviens toujours aux mêmes principes : une règle par besoin métier, des groupes pour les équipes, des scripts wrappers pour l’automatisation, et des fichiers séparés dans /etc/sudoers.d/ plutôt qu’un énorme bloc central difficile à relire. Cette approche est simple, mais elle tient mieux dans le temps que les exceptions improvisées.
- Je limite chaque règle à une seule intention opérationnelle.
- Je teste systématiquement avec
visudoavant de livrer. - Je versionne les fichiers de règles comme du code d’infrastructure.
- Je préfère un groupe bien nommé à plusieurs comptes isolés mal documentés.
- Je réserve les accès sans mot de passe aux tâches non interactives et stables.
Si je devais résumer l’approche en une phrase, je dirais ceci : autorise le moins possible, garde les règles lisibles, et traite chaque modification comme un changement de sécurité à part entière. C’est cette discipline qui transforme la politique sudo en outil de contrôle fin, au lieu d’en faire une porte ouverte déguisée.
