Utilisateurs, groupes, rôles, pools : modèle de droits

Day 1 · DéployerNiveau 2 · OpérerCoursRédigé · à valider en lab

Dans Proxmox VE, un droit est toujours un triplet qui (utilisateur, groupe ou jeton API) + quoi (un rôle, c'est-à-dire un ensemble de privilèges) + où (un chemin d'ACL). Comprendre ce triplet suffit pour donner à chaque équipe exactement ce dont elle a besoin, sans partager le compte root@pam.

Notions clés

Objet	Ce que c'est	Exemple
Utilisateur	Identité nom@realm. Le realm dit qui vérifie le mot de passe.	jdupont@pve, jdupont@ad-corp
Groupe	Ensemble d'utilisateurs. On pose les droits sur le groupe, pas sur la personne.	admins-infra, dev
Rôle	Liste nommée de privilèges (VM.PowerMgmt, Datastore.Audit…).	PVEVMUser
Chemin (ACL path)	Objet de l'arborescence sur lequel s'applique le rôle.	/, /vms/101, /storage/pbs-local, /pool/dev
Pool	Regroupement logique de VM et de stockages pour poser un droit d'un coup.	pool dev contenant VM 201 à 210
Jeton API	Identité technique user@realm!jeton, droits égaux ou inférieurs à ceux de l'utilisateur.	terraform@pve!ci

La configuration est stockée dans /etc/pve/user.cfg (utilisateurs, groupes, ACL, pools) et /etc/pve/domains.cfg (realms). Ces fichiers sont répliqués sur tout le cluster par pmxcfs : un droit posé sur pve01 vaut immédiatement sur pve02 et pve03.

Les chemins d'ACL

Chemin	Couvre
/	Tout le datacenter. À réserver aux administrateurs.
/nodes/{node}	Un nœud (console shell, mises à jour, réseau).
/vms et /vms/{vmid}	Toutes les VM/CT, ou une seule.
/storage/{storeid}	Un stockage (/storage/pbs-local, /storage/ceph-vm).
/pool/{poolname}	Toutes les VM et stockages membres du pool.
/access, /access/groups, /access/realms/{realm}	Gestion des utilisateurs, groupes et realms.
/sdn/..., /mapping/...	Zones/VNets SDN et mappings de ressources (PCI, USB).

Les rôles prédéfinis utiles

Rôle	Usage type
Administrator	Tous les privilèges. Comptes d'administration nominatifs uniquement.
PVEAdmin	Presque tout, sauf les réglages système sensibles (Sys.Modify…) et la gestion des droits.
PVEAuditor	Lecture seule. Idéal pour la supervision et les auditeurs.
PVEVMAdmin	Administration complète des VM.
PVEVMUser	Utiliser une VM : console, démarrage/arrêt, sauvegarde, CD-ROM.
PVEDatastoreUser	Allouer de l'espace et sauvegarder sur un stockage.
PVEDatastoreAdmin	Créer et administrer des stockages.
PVEPoolAdmin / PVEPoolUser	Gérer / voir un pool.
PVESDNUser, PVEMappingUser	Utiliser un VNet, un mapping PCI/USB.
NoAccess	Interdit tout sur le chemin, même si un autre rôle l'autorise.

La liste complète (17 rôles en PVE 9) est visible dans Datacenter → Permissions → Roles ou avec pveum role list. En PVE 9, le privilège VM.Monitor a disparu au profit de privilèges VM.GuestAgent.* plus fins : un rôle personnalisé hérité de PVE 8 qui le contenait doit être revu lors de la mise à niveau.

Comment le droit effectif est calculé

flowchart TD
    A[Requête de jdupont@ad-corp sur /vms/101] --> B{ACL sur /vms/101 ?}
    B -- oui --> E[Rôle le plus spécifique retenu]
    B -- non --> C{ACL héritée de /vms ou / avec propagate=1 ?}
    C -- oui --> E
    C -- non --> D[Refus : 403 Permission check failed]
    E --> F{NoAccess sur ce chemin ?}
    F -- oui --> D
    F -- non --> G[Privilèges accordés]

Règles à retenir :

• Propagation : cochée par défaut, une ACL sur /vms s'applique à /vms/101.
• Le plus spécifique gagne : une ACL sur /vms/101 remplace celle héritée de /.
• Utilisateur avant groupe : un droit posé sur l'utilisateur prime sur celui de son groupe au même niveau.
• NoAccess annule tout sur le chemin concerné.
• Jeton à privilèges séparés : ses droits sont l'intersection de ses propres ACL et de celles de son utilisateur.

Exemple : équipe de développement cantonnée à son pool

pveum group add dev --comment "Equipe dev"
pveum user add jdupont@pve --comment "Jean Dupont" --groups dev
pveum passwd jdupont@pve
pveum pool add dev --comment "VM de developpement"
pveum pool modify dev --vms 201,202,203 --storage ceph-vm
pveum acl modify /pool/dev --group dev --role PVEVMAdmin
pveum acl modify /storage/ceph-vm --group dev --role PVEDatastoreUser
pveum user permissions jdupont@pve      # droits effectifs calculés

GUI : Datacenter → Permissions → Groups / Users / Pools, puis Permissions → Add → Group Permission.

Recommandations MSP

• Un compte nominatif par personne, dans un realm d'annuaire (AD/LDAP/OIDC) quand il existe. root@pam reste un compte de secours, avec mot de passe au coffre et 2FA.
• Poser les droits sur des groupes, jamais sur des individus : un départ se gère dans l'annuaire.
• Le compte du MSP (par exemple msp-admin@pve) est un compte distinct, Administrator sur /, à ne pas supprimer ni modifier : il conditionne l'intervention sous contrat N2/N3. Voir la matrice de responsabilité.
• Supervision et outils d'automatisation : comptes de service avec jetons API, voir Jetons API et comptes de service.
• Créer un rôle personnalisé plutôt que donner PVEAdmin « pour que ça marche ». Exemple : pveum role add VM-Operateur --privs "VM.Audit VM.Console VM.PowerMgmt".

Pièges vus en support

• Droit posé sur /vms/101 mais pas sur le stockage : l'utilisateur ne peut ni ajouter de disque ni sauvegarder. Il faut aussi Datastore.AllocateSpace sur /storage/....
• Utilisateur créé dans @pve alors qu'il existe dans l'AD : deux identités, deux mots de passe, un compte oublié au départ du salarié.
• NoAccess posé « pour tester » sur / à un groupe dont fait partie un administrateur : il perd la main sur tout.
• Une VM ajoutée au cluster n'entre pas automatiquement dans un pool : penser à l'option Resource Pool à la création, ou à pveum pool modify.
• Suppression d'un utilisateur @pam dans PVE : le compte Linux existe toujours sur le nœud. Le désactiver aussi côté système.

Testez-vous

1. Un utilisateur a PVEAdmin sur / via son groupe et PVEAuditor directement sur /vms/101. Peut-il arrêter la VM 101 ?

   Réponse

   Non. L'ACL la plus spécifique (/vms/101) et posée sur l'utilisateur prime : il n'a que la lecture sur cette VM.

2. Quelle commande affiche les droits réellement accordés à jdupont@pve ?

   Réponse

   pveum user permissions jdupont@pve. En GUI : Datacenter → Permissions → Users, bouton Permissions.

3. Pourquoi utiliser un pool plutôt que des ACL par VM ?

   Réponse

   Une seule ACL sur /pool/<nom> couvre toutes les VM et stockages membres. On gère l'appartenance au pool, pas des dizaines d'ACL.

4. Où sont stockés utilisateurs, groupes et ACL ?

   Réponse

   Dans /etc/pve/user.cfg, répliqué sur tous les nœuds par pmxcfs. Les realms sont dans /etc/pve/domains.cfg.

Pour aller plus loin

• Authentification AD, LDAP, OpenID Connect, 2FA
• Jetons API et comptes de service
• Documentation officielle : User Management · pveum(1)