RBAC Proxmox VE : comprendre les permissions et faire les bons choix

Qui peut faire quoi sur votre cluster Proxmox ? Cette question devient critique dès que vous n’êtes plus seul à utiliser le serveur — ou dès que vous automatisez avec des scripts. Ce guide vous donne les modèles mentaux pour comprendre comment Proxmox gère les permissions, puis les critères pour concevoir une stratégie adaptée à votre situation.

Le modèle mental RBAC : Sujet × Rôle × Path

Avant de créer des utilisateurs ou d’attribuer des permissions, vous devez comprendre comment Proxmox décide si une action est autorisée. Sans ce modèle mental, vous allez soit tout autoriser (risqué), soit vous retrouver bloqué.

La formule de base

Chaque autorisation dans Proxmox combine 3 éléments :

Autorisation = Sujet × Rôle × Path

Élément	Question	Exemples
Sujet	Qui demande ?	`alice@pve`, `@devs`, `backup-token`
Rôle	Quelles actions peut-il faire ?	`PVEVMUser`, `PVEAdmin`, `PVEAuditor`
Path	Sur quoi peut-il agir ?	`/pool/dev`, `/vms/100`, `/storage/backup`

La phrase clé : un utilisateur alice@pve ayant le rôle PVEVMUser sur le path /pool/dev peut démarrer/arrêter les VM du pool dev, mais rien d’autre.

Modèle RBAC Proxmox : Sujet + Rôle + Path = ACL

Pourquoi cette distinction compte

Cette architecture à 3 dimensions a des conséquences pratiques :

Un même utilisateur peut avoir plusieurs rôles sur différents paths
Un même rôle peut être attribué à plusieurs sujets
Les permissions se cumulent (pas d’override négatif)
L’héritage descend le long des paths (attention au /)

Les briques du système RBAC

Proxmox organise les permissions autour de 4 types d’objets. Comprendre chacun vous permet de concevoir une stratégie efficace.

Les sujets : utilisateurs, groupes et tokens

Un sujet est qui demande l’accès. Proxmox distingue 3 types :

Type	Format	Cas d’usage
Utilisateur	`alice@realm`	Accès humain via l’interface ou l’API
Groupe	`@devs`	Regrouper des utilisateurs qui ont les mêmes droits
API Token	`alice@pve!backup`	Automatisation (scripts, Ansible, Terraform)

Les realms : le suffixe après @ indique comment l’utilisateur s’authentifie :

Realm	Signification	Cas d’usage
`@pam`	Compte Linux local	root, comptes système
`@pve`	Compte Proxmox natif	Utilisateurs créés dans Proxmox
`@ldap` / `@ad`	Annuaire externe	Entreprise avec Active Directory

Point clé : root@pam est le super-utilisateur Linux. Il a tous les droits quoi qu’il arrive — les ACL Proxmox ne le limitent pas. C’est normal, mais c’est aussi pourquoi vous ne devez pas l’utiliser pour tout.

Les rôles : ensembles de privilèges

Un rôle est un paquet de privilèges (permissions atomiques). Proxmox fournit des rôles prédéfinis :

Rôle	Ce qu’il permet	Cas d’usage
NoAccess	Rien (bloque l’héritage)	Interdire explicitement
PVEAuditor	Lecture seule	Monitoring, audit, supervision
PVEVMUser	Console VM, démarrer/arrêter	Opérateurs quotidiens
PVEVMAdmin	Créer/supprimer/configurer VM	Administrateurs VM
PVEAdmin	Tout sauf infra (stockage, réseau)	Administrateurs applicatifs
Administrator	Tout	Super-admin (à éviter sur `/`)

Les privilèges : permissions atomiques

Chaque rôle est composé de privilèges. Vous n’attribuez jamais un privilège directement — vous passez toujours par un rôle. Mais comprendre les privilèges aide à choisir le bon rôle.

Quelques privilèges importants :

Privilège	Ce qu’il permet
`VM.PowerMgmt`	Démarrer, arrêter, redémarrer
`VM.Console`	Accéder à la console (VNC/SPICE)
`VM.Config.*`	Modifier la configuration VM
`VM.Allocate`	Créer/supprimer des VM
`Datastore.Allocate`	Créer/supprimer sur un stockage
`Sys.Audit`	Voir la configuration système
`Sys.Modify`	Modifier la configuration système

Point clé : VM.Console donne accès à ce qui s’affiche dans la VM. Si quelqu’un y est connecté en root, vous voyez (et pouvez agir sur) sa session. C’est un accès puissant.

Les paths : l’arborescence des objets

Un path désigne où s’applique une permission. Proxmox organise tous les objets en arborescence :

/                          ← Racine (tout Proxmox)
├── /access                ← Gestion des users/groupes/ACL
├── /nodes                 ← Serveurs physiques
│   └── /nodes/pve1        ← Un serveur spécifique
├── /vms                   ← Toutes les VM (par VMID)
│   └── /vms/100           ← VM n°100
├── /storage               ← Stockages
│   └── /storage/local     ← Un stockage spécifique
└── /pool                  ← Pools de ressources
    └── /pool/dev          ← Pool "dev"

L’héritage : une permission sur un path s’applique à tous les chemins en dessous.

Permission sur…	S’applique à…
`/`	Tout Proxmox (danger !)
`/nodes`	Tous les serveurs
`/nodes/pve1`	Un seul serveur
`/pool/dev`	Toutes les VM du pool dev
`/vms/100`	Une seule VM

Les pools : regrouper pour simplifier

Un pool est un conteneur logique qui regroupe plusieurs VM/conteneurs. C’est l’unité idéale pour attribuer des permissions.

Approche	Problème	Solution
Permissions par VM	Maintenance pénible : ajouter/retirer chaque VM	Utiliser des pools
Permissions par node	Trop large : donne accès à toutes les VM du serveur	Utiliser des pools
Permissions par pool	✅ Ajouter une VM au pool = elle hérite automatiquement	Approche recommandée

Exemple concret :

Créer le pool dev
Attribuer PVEVMUser au groupe @devs sur /pool/dev
Ajouter les VM de dev dans le pool
→ Les développeurs peuvent gérer ces VM, rien d’autre

Cycle de vie d’un accès

Comprendre le flux d’une demande d’accès aide à débugger les problèmes de permissions.

Comment Proxmox vérifie une action

Quand un utilisateur tente une action, Proxmox suit cette logique :

Identifier le sujet : qui demande ? (user, group, token)
Identifier l’objet : sur quoi ? (VM, storage, node…)
Calculer le path : quel est le chemin de l’objet ?
Chercher les ACL : quelles ACL s’appliquent à ce sujet sur ce path ou ses parents ?
Vérifier les privilèges : les rôles trouvés contiennent-ils le privilège requis ?
Décision : si oui → autorisé ; si non → refusé

Ce que ça implique en pratique

Situation	Ce qui se passe
ACL sur `/pool/dev` + VM dans le pool	✅ L’utilisateur peut agir sur la VM
ACL sur `/pool/dev` + VM hors du pool	❌ Pas d’accès (même si l’ACL existe)
ACL sur `/vms/100` uniquement	✅ Accès à VM 100 seulement
Aucune ACL trouvée	❌ Refus par défaut

Point clé : Proxmox refuse par défaut. Si aucune ACL n’accorde le privilège, l’action est interdite.

Les 4 profils types

Plutôt que de créer des permissions au cas par cas, partez de profils métier et adaptez.

Profil 1 : Audit / Lecture seule

Besoin : voir l’état du cluster sans pouvoir modifier quoi que ce soit.

Élément	Valeur
Rôle	`PVEAuditor`
Path	`/` (tout voir) ou `/pool/X` (périmètre limité)
Usage	Monitoring, revue de conformité, support N1

Ce qu’il peut faire : voir les configurations, consulter les logs, regarder les métriques.

Ce qu’il ne peut pas faire : démarrer/arrêter des VM, modifier des configs, supprimer quoi que ce soit.

Profil 2 : Opérateur VM

Besoin : gérer les VM au quotidien (démarrer, arrêter, console) sans pouvoir en créer ou les supprimer.

Élément	Valeur
Rôle	`PVEVMUser`
Path	`/pool/X` (recommandé) ou `/vms/Y` (VM spécifique)
Usage	Équipe applicative, support N2, développeurs

Ce qu’il peut faire : démarrer/arrêter, accéder à la console, voir la configuration.

Ce qu’il ne peut pas faire : créer des VM, modifier la configuration matérielle, supprimer.

Profil 3 : Administrateur Proxmox (infra)

Besoin : gérer l’infrastructure (stockage, réseau, cluster) mais pas forcément les VM applicatives.

Élément	Valeur
Rôle	`PVEAdmin` ou rôle custom
Path	`/nodes`, `/storage`
Usage	Équipe infrastructure, SRE

Ce qu’il peut faire : configurer le réseau, gérer les stockages, administrer les nœuds.

Ce qu’il ne peut pas faire : accéder aux VM d’un autre pool (si séparation par pool).

Profil 4 : Automatisation (API Token)

Besoin : scripts, Ansible, Terraform qui doivent interagir avec l’API Proxmox.

Élément	Valeur
Type	API Token (pas un utilisateur)
Rôle	Le minimum nécessaire à la tâche
Path	Le plus restreint possible

Exemples :

Automatisation	Rôle	Path
Backup automatique	`PVEDatastoreUser`	`/storage/backup`
Provisionning Terraform	`PVEVMAdmin`	`/pool/terraform`
Monitoring	`PVEAuditor`	`/`

Les pièges fréquents

1. Le piège du slash `/`

Symptôme : un utilisateur a accès à tout alors qu’il ne devrait pas.

Cause : permission accordée sur / au lieu du path spécifique.

Solution : toujours utiliser le path complet (/pool/dev, pas /).

2. Mauvaise granularité

Symptôme : impossible de donner accès à un sous-ensemble de VM.

Cause : permissions sur /nodes/pve1 (trop large) au lieu de /pool/X.

Solution : utiliser les pools pour regrouper les ressources par usage.

3. Tokens trop puissants

Symptôme : un token de backup peut créer des VM.

Cause : rôle trop permissif ou path trop large.

Solution : un token = une tâche = le rôle minimum.

4. Confusion de realms

Symptôme : l’utilisateur ne peut pas se connecter ou a des droits différents de ceux attendus.

Cause : confusion entre alice@pam, alice@pve, alice@ldap.

Solution : chaque realm est indépendant. alice@pve n’est pas alice@pam.

5. Accès aux backups = données sensibles

Symptôme : quelqu’un peut restaurer une VM de prod qu’il ne devrait pas voir.

Cause : accès au stockage de backup sans réflexion sur ce qu’il contient.

Solution : les backups contiennent les données des VM. Limitez l’accès en lecture/restore.

6. Console = pouvoir

Symptôme : un utilisateur “lecture seule” peut quand même agir sur une VM.

Cause : accès console permet de voir (et utiliser) les sessions ouvertes dans la VM.

Solution : VM.Console est un privilège sensible. Ne le donnez pas à l’audit.

Stratégie recommandée

Organiser par pools

La structure la plus maintenable :

Pool	Contenu	Groupe(s)	Rôle(s)
`prod`	VM de production	`@ops`	`PVEVMUser`
`preprod`	VM de préproduction	`@ops`, `@devs`	`PVEVMUser`
`dev`	VM de développement	`@devs`	`PVEVMAdmin`
`infra`	VM d’infrastructure	`@admins`	`PVEAdmin`

Pourquoi ça fonctionne :

Ajouter une VM au bon pool = permissions automatiques
Changer les droits d’une équipe = modifier une seule ACL
Audit clair : qui a accès à quoi

Tokens par automatisation

Automatisation	Token	Rôle	Path
Backups PBS	`backup-bot@pve!pbs`	`PVEDatastoreUser`	`/storage/pbs`
Terraform dev	`terraform@pve!dev`	`PVEVMAdmin`	`/pool/dev`
Monitoring	`monitoring@pve!zabbix`	`PVEAuditor`	`/`

Revue périodique

Tous les trimestres :

Lister les ACL actives : des permissions obsolètes ?
Vérifier les tokens : utilisés ? à rotation ?
Valider les groupes : membres à jour ?

Vérifier vos permissions

Sans entrer dans les procédures de création, voici comment lire l’état de votre RBAC :

# Lister tous les utilisateurs
pveum user list

# Lister les groupes
pveum group list

# Lister les rôles disponibles
pveum role list

# Voir les ACL (qui a quoi où)
pveum acl list

# Voir les tokens d'un utilisateur
pveum user token list alice@pve

# Voir les privilèges d'un rôle
pveum role list PVEVMUser --output json

Ces commandes sont de la lecture, pas de la modification.

À retenir

Autorisation = Sujet × Rôle × Path : comprendre cette formule évite 90% des erreurs de permissions.
Le slash / est dangereux : une permission sur / se propage partout. Utilisez les paths complets.
Les pools simplifient tout : regroupez les VM par usage et attribuez les permissions sur les pools, pas sur les VM individuelles.
Un token = une tâche : pour l’automatisation, créez un token dédié avec le minimum de droits.
root@pam bypass tout : le compte root Linux n’est pas limité par les ACL Proxmox. Utilisez-le uniquement pour l’urgence.
Console = accès sensible : VM.Console permet de voir et utiliser les sessions ouvertes. Ne le donnez pas aux auditeurs.
Les backups contiennent les données : l’accès au stockage backup = accès aux données des VM. Limitez-le.
Revue trimestrielle : permissions, tokens, groupes. Les droits s’accumulent si on ne nettoie pas.

Prochaines étapes

Installation Proxmox Installer Proxmox VE 8 sur votre serveur

Concepts stockage Comprendre LVM-thin, ZFS et Directory

Concepts réseau Bridges, VLAN et NAT dans Proxmox

Interface Proxmox Naviguer efficacement dans l'interface web