Dans un cloud privé Proxmox avec stockage hyperconvergé CEPH, la problématique de la délégation d’accès est récurrente : comment permettre à un utilisateur de gérer pleinement les machines virtuelles sans pour autant lui donner la main sur la configuration du cluster ? Proxmox dispose d’un système de contrôle d’accès basé sur les rôles (RBAC) particulièrement bien pensé. Voyons ensemble comment le mettre en oeuvre.

Le modèle RBAC de Proxmox

Proxmox VE implémente un modèle RBAC articulé autour de cinq concepts fondamentaux :

  • Realms (Domaines d’authentification) : les sources d’authentification supportées. Par défaut, pam (Linux PAM, pour les comptes système) et pve (base interne Proxmox). On peut aussi connecter un Active Directory ou un annuaire LDAP.
  • Users (Utilisateurs) : identifiés sous la forme login@realm, par exemple alice@pve ou bob@pam.
  • Groups (Groupes) : permettent de regrouper des utilisateurs pour leur affecter des droits en une seule opération.
  • Roles (Rôles) : un ensemble de permissions atomiques. Proxmox fournit des rôles prédéfinis, mais il est possible d’en créer des personnalisés.
  • ACL (Access Control Lists) : la colle qui lie un utilisateur (ou groupe) à un rôle sur un chemin précis de l’arborescence Proxmox.

L’arborescence des chemins (paths)

Tout dans Proxmox est organisé selon une arborescence de chemins sur lesquels on applique les droits :

  • / — Racine (accès global à tout)
  • /nodes — Les nœuds du cluster
  • /nodes/{node} — Un nœud précis
  • /vms — Toutes les VMs et conteneurs
  • /vms/{vmid} — Une VM précise
  • /storage — Tous les stockages
  • /storage/{storeid} — Un stockage précis
  • /pool/{poolname} — Un pool de ressources
  • /sdn — La couche réseau SDN

C’est cette granularité sur les chemins qui permet de cloêsonner précisément les accès.

Les rôles prédéfinis dans Proxmox

Proxmox propose plusieurs rôles built-in. Voici les principaux :

Rôle Description
Administrator Accès total à tout (équivalent root)
PVEVMAdmin Administration complète des VMs (create, delete, migrate, snapshot, resize…)
PVEVMUser Usage basique des VMs (console, start/stop, mais pas de création)
PVEDatastoreAdmin Administration complète des stockages
PVEDatastoreUser Utilisation des stockages (allouer de l’espace)
PVEAuditor Lecture seule sur tout
PVESysAdmin Administration système des nœuds
PVEPoolAdmin Administration des pools de ressources
NoAccess Interdit explicitement l’accès (permet de bloquer un héritage)

Notre cas d’usage : un administrateur VM sans accès cluster

L’objectif est le suivant : donner à un utilisateur la capacité de :

  • ✅ Démarrer / arrêter / suspendre des VMs
  • ✅ Créer et supprimer des VMs
  • ✅ Prendre des snapshots et effectuer des rollbacks
  • ✅ Modifier le CPU et la RAM (hot-plug)
  • ✅ Ajouter des disques
  • ✅ Cloner des VMs
  • ✅ Migrer des VMs entre nœuds
  • ✅ Modifier la configuration réseau des VMs
  • ❌ Toucher à la configuration du cluster (nœuds, CEPH, réseau SDN global, utilisateurs…)

Pourquoi le rôle PVEVMAdmin est la bonne réponse

Le rôle PVEVMAdmin regroupe exactement les permissions nécessaires pour couvrir l’intégralité du périmètre demandé :

Permission Action couverte
VM.Allocate Créer et supprimer des VMs
VM.Clone Cloner des VMs
VM.Migrate Migrer des VMs entre nœuds
VM.PowerMgmt Start / Stop / Reboot / Suspend
VM.Snapshot Créer et supprimer des snapshots
VM.Snapshot.Rollback Restaurer un snapshot
VM.Config.CPU Modifier le nombre de vCPUs
VM.Config.Memory Modifier la RAM
VM.Config.Disk Ajouter / retirer des disques
VM.Config.Network Modifier les interfaces réseau des VMs
VM.Config.Options Modifier les options générales
VM.Config.CDROM Monter/démonter des ISOs
VM.Config.HWType Modifier le type de matériel émulé
VM.Console Accès console (VNC/SPICE/xterm)
VM.Audit Voir la configuration des VMs
VM.Backup Lancer des sauvegardes
VM.Monitor Accès au monitor QEMU

La clé est d’appliquer ce rôle uniquement sur le chemin /vms et non sur /. Cela signifie que l’utilisateur n’aura aucun accès à la gestion des nœuds (/nodes), aux stockages (/storage), ni à la configuration CEPH ou SDN — sauf ce qu’on lui accorde explicitement.

Il faudra cependant lui accorder un droit minimal sur les stockages pour qu’il puisse allouer des disques, et sur les nœuds pour la migration des VMs.

Mise en oeuvre — Via l’interface web Proxmox

Étape 1 : Créer l’utilisateur

  1. Dans l’interface Proxmox, aller dans Datacenter → Users.
  2. Cliquer sur Add.
  3. Remplir les champs :
    • User name : vmadmin
    • Realm : pve (authentification interne Proxmox)
    • Password : définir un mot de passe sécurisé
    • Enabled : coché
  4. Valider avec Add.

Étape 2 : (Optionnel) Créer un groupe

Si vous avez plusieurs utilisateurs à gérer avec les mêmes droits, créez un groupe :

  1. Aller dans Datacenter → Groups.
  2. Cliquer sur Create, nommer le groupe vm-operators.
  3. Aller ensuite dans Datacenter → Users, éditer l’utilisateur vmadmin@pve et l’ajouter au groupe vm-operators.

Étape 3 : Assigner les ACL

Aller dans Datacenter → Permissions et cliquer sur Add → User Permission (ou Group Permission si vous avez créé un groupe) pour chacune des ACL suivantes :

ACL 1 — Gestion des VMs :

  • Path : /vms
  • User : vmadmin@pve
  • Role : PVEVMAdmin
  • Propagate : coché (s’applique à toutes les VMs)

ACL 2 — Utilisation des stockages (pour allouer des disques) :

  • Path : /storage
  • User : vmadmin@pve
  • Role : PVEDatastoreUser
  • Propagate : coché

ACL 3 — Accès aux nœuds pour la migration :

  • Path : /nodes
  • User : vmadmin@pve
  • Role : PVEAuditor
  • Propagate : coché

⚠️ Le rôle PVEAuditor sur /nodes donne uniquement un accès en lecture aux informations des nœuds. C’est nécessaire pour que Proxmox autorise la migration (il doit voir les nœuds cibles), mais cela n’ouvre aucun droit d’administration sur les nœuds eux-mêmes.

Mise en oeuvre — Via la CLI (pveum)

La totalité de la configuration peut se faire en ligne de commande sur un nœud Proxmox avec l’outil pveum. C’est la méthode à privilégier pour l’automatisation et la reproductibilité.

Création de l’utilisateur

# Créer l'utilisateur vmadmin dans le realm pve
pveum useradd vmadmin@pve --comment "Administrateur VMs"

# Définir le mot de passe
pveum passwd vmadmin@pve

Création d’un groupe (optionnel)

# Créer le groupe
pveum groupadd vm-operators --comment "Opérateurs VMs"

# Ajouter l'utilisateur au groupe
pveum usermod vmadmin@pve --groups vm-operators

Assignation des ACL

# ACL 1 : PVEVMAdmin sur toutes les VMs
pveum aclmod /vms --users vmadmin@pve --roles PVEVMAdmin

# (Alternative avec un groupe)
pveum aclmod /vms --groups vm-operators --roles PVEVMAdmin

# ACL 2 : PVEDatastoreUser sur tous les stockages
pveum aclmod /storage --users vmadmin@pve --roles PVEDatastoreUser

# ACL 3 : PVEAuditor sur les nœuds (pour la migration)
pveum aclmod /nodes --users vmadmin@pve --roles PVEAuditor

Vérification des droits appliqués

# Lister toutes les ACL configurées
pveum acl list

# Vérifier les permissions effectives d'un utilisateur
pveum user permissions vmadmin@pve

# Lister les utilisateurs
pveum user list

# Lister les groupes
pveum group list

Aller plus loin : créer un rôle personnalisé

Si vous souhaitez affiner davantage les droits (par exemple, retirer la permission VM.Monitor qui donne accès au monitor QEMU, ou VM.Config.HWType pour interdire de changer le type de matériel émulé), vous pouvez créer un rôle personnalisé :

# Créer un rôle personnalisé "VMOperator" avec les permissions exactes souhaitées
pveum roleadd VMOperator 
  --privs "VM.Allocate,VM.Clone,VM.Migrate,VM.PowerMgmt,VM.Snapshot,VM.Snapshot.Rollback,VM.Config.CPU,VM.Config.Memory,VM.Config.Disk,VM.Config.Network,VM.Config.Options,VM.Config.CDROM,VM.Console,VM.Audit,VM.Backup"

# Vérifier le contenu du rôle
pveum role list
pveum role permissions VMOperator

# Assigner ce rôle à la place de PVEVMAdmin
pveum aclmod /vms --users vmadmin@pve --roles VMOperator

Cette approche est particulièrement utile en environnement de production où l’on veut appliquer le principe du moindre privilège.

Restreindre l’accès à un pool de VMs spécifique

Pour aller encore plus loin dans le cloisonnement, Proxmox permet de créer des pools de ressources regroupant VMs et stockages. On peut ensuite affecter les droits sur un pool plutôt que sur /vms globalement :

# Créer un pool
pveum pool add production --comment "Pool VMs de production"

# Ajouter des VMs au pool via l'interface web :
# Datacenter -> Pools -> sélectionner le pool -> Add

# Donner accès à l'utilisateur uniquement sur ce pool
pveum aclmod /pool/production --users vmadmin@pve --roles PVEVMAdmin

De cette façon, l’utilisateur ne voit même pas les VMs qui ne font pas partie de son pool. C’est idéal dans un contexte multi-tenant.

Points de vigilance avec CEPH

Dans un contexte hyperconvergé avec CEPH, quelques points méritent attention :

  • Les stockages CEPH apparaissent comme des datastores Proxmox standards (RBD). Le rôle PVEDatastoreUser sur /storage suffira pour que l’utilisateur puisse allouer des disques sur le pool CEPH sans avoir accès à l’administration CEPH elle-même (pas de gestion des OSD, PG, pools CEPH…).
  • La gestion CEPH (ajout/suppression d’OSD, création de pools, monitoring CEPH) reste accessible uniquement via Datacenter → CEPH et nécessite le rôle Administrator ou PVESysAdmin sur / — ce que notre utilisateur vmadmin@pve n’a pas.
  • Les snapshots avec CEPH (snapshots RBD) fonctionnent normalement avec la permission VM.Snapshot accordée via PVEVMAdmin.
  • La migration live (live migration) entre nœuds avec CEPH fonctionne également, car le stockage étant partagé entre tous les nœuds, il n’y a pas de copie de données à effectuer — seul le contexte d’exécution est transféré.

Récapitulatif des commandes

## ---- Création de l'utilisateur ----
pveum useradd vmadmin@pve --comment "Administrateur VMs"
pveum passwd vmadmin@pve

## ---- (Optionnel) Groupe ----
pveum groupadd vm-operators
pveum usermod vmadmin@pve --groups vm-operators

## ---- Assignation des droits ----
# Gestion complète des VMs
pveum aclmod /vms --users vmadmin@pve --roles PVEVMAdmin

# Allocation d'espace sur les stockages (CEPH inclus)
pveum aclmod /storage --users vmadmin@pve --roles PVEDatastoreUser

# Visibilité des nœuds pour la migration
pveum aclmod /nodes --users vmadmin@pve --roles PVEAuditor

## ---- Vérification ----
pveum acl list
pveum user permissions vmadmin@pve

Conclusion

Le système RBAC de Proxmox est à la fois puissant et simple à mettre en oeuvre. En combinant le rôle PVEVMAdmin sur /vms, PVEDatastoreUser sur /storage et PVEAuditor sur /nodes, on obtient exactement le profil souhaité : un utilisateur capable de faire tout ce qui touche aux machines virtuelles (création, suppression, clonage, migration, snapshots, redimensionnement CPU/RAM, ajout de disques, configuration réseau) sans jamais pouvoir toucher à la configuration du cluster, des nœuds, de CEPH ou du SDN.

La granularité des chemins et la possibilité de créer des rôles personnalisés font de Proxmox un hyperviseur particulièrement adapté aux environnements multi-utilisateurs et aux organisations qui souhaitent appliquer le principe du moindre privilège à leur infrastructure de virtualisation.

📚 À lire aussi