Proxmox « Permission refusée » dans Datacenter : rôles et ACL bien faits

« Permission refusée » dans la vue Datacenter de Proxmox ressemble à une petite gêne — jusqu’à ce que cela bloque les sauvegardes, casse l’automatisation et transforme votre astreinte en une danse interprétative autour des chemins ACL.

Ce n’est pas un problème mystique. Les permissions Proxmox sont déterministes. La douleur vient des humains : hypothèses erronées sur l’héritage des ACL, confusion entre les chemins Datacenter vs node vs VM, et définitions de rôles qui poussent comme de la moisissure dans une cave.

Le modèle mental des permissions qui fonctionne réellement

Les permissions Proxmox ne sont pas compliquées. Elles sont simplement en couches. Si vous ne gardez pas les couches claires, vous « réparerez » l’accès en collant Administrator sur un utilisateur à / et considérerez le problème résolu. C’est comme réparer un robinet qui fuit en coupant l’alimentation en eau de toute la ville.

Voici le modèle dont vous avez besoin :

• Identité : utilisateur, groupe ou jeton API. Stockée dans un realm (PAM, PVE, LDAP/AD, OpenID, etc.).
• Rôle : un ensemble nommé de privilèges (par exemple, PVEVMAdmin, PVEAuditor).
• ACL : lie identité → rôle sur un chemin, éventuellement avec propagation.
• Chemin : l’arborescence des ressources : /, /dc, /nodes/pve01, /vms/101, /storage/nvme-ssd, /pool/Dev, etc.
• Privilèges effectifs : Proxmox calcule ce que vous pouvez faire au moment de l’accès, à partir de toutes les ACL correspondantes.

« Permission refusée dans Datacenter » signifie généralement : l’utilisateur peut s’authentifier, mais il lui manque un ou plusieurs privilèges requis pour afficher ou manipuler quelque chose au scope /dc (ou l’interface a essayé de le récupérer à ce scope).

Deux vérités opérationnelles :

1. La plupart des pages du GUI interrogent plusieurs endpoints. Vous pouvez avoir le droit de voir une VM, mais la barre latérale demande des ressources de cluster, l’état du stockage ou des métriques du node. Un appel refusé peut casser toute la vue.
2. Le chemin est le contrat. Si l’ACL est sur /nodes/pve01 mais que vous regardez quelque chose sous /dc (Datacenter), n’attendez pas de miracles.

Blague #1 : Donner à tout le monde Administrator à / revient à résoudre les files de tickets en débranchant le téléphone du helpdesk. Le silence est réel, mais le désastre aussi.

Faits intéressants et contexte historique (les points importants)

Ce ne sont pas des anecdotes pour un quiz. Elles expliquent pourquoi les permissions Proxmox sont comme elles sont et pourquoi certains modes de défaillance se répètent.

1. Le système de permissions de Proxmox est fortement influencé par la mentalité Unix : identités et groupes mappés sur un arbre de ressources. C’est pour ça que les chemins donnent une impression de « système de fichiers ».
2. Les rôles par défaut encodent une intention opérationnelle : PVEVMAdmin n’est pas « admin », c’est « admin des VMs », et il ne donne volontairement pas tout au scope Datacenter.
3. La configuration du cluster est distribuée : dans un cluster, les données de permission sont partagées via le système de fichiers du cluster. Un nœud partitionné peut afficher des ACL obsolètes et embrouiller votre dépannage.
4. Historiquement, les UIs des produits infra sur-consultent : les premières consoles SPA d’administration interrogeaient des endpoints larges pour peupler les tableaux de bord. Le comportement du GUI Proxmox hérite de ce pattern.
5. Les permissions fines sur le stockage sont une attente récente : les anciennes piles de virtualisation supposaient « les admins stockage sont admins hyperviseur ». Dans Proxmox, les objets de stockage ont des chemins ACL explicites, ce qui est bien — jusqu’à ce qu’on les oublie.
6. Les tokens API répondent à la réalité de l’automatisation : des mots de passe longs dans des scripts sont une dette opérationnelle. Les tokens sont meilleurs, mais seulement si vous les scopez correctement.
7. Le principe du moindre privilège s’est répandu à cause des compromissions, pas par esthétique : l’expansion des privilèges n’est pas un problème esthétique ; c’est un multiplicateur d’incidents.
8. Le RBAC de Proxmox est conçu pour des équipes mixtes : admins virtualisation, équipes stockage, auditeurs et équipes applicatives peuvent coexister — si vous arrêtez de tout faire « Administrator ».
9. La propagation est un piège classique : les permissions héritées sont pratiques, mais c’est aussi ainsi que l’« accès temporaire » devient « accès pour toujours ».

Comment Proxmox évalue les rôles et les ACL (et pourquoi votre GUI omet des choses)

Les rôles sont des ensembles de privilèges

Un rôle est une liste nommée de privilèges. Les privilèges sont des unités atomiques comme VM.Audit, VM.PowerMgmt, Datastore.Allocate, Sys.Audit, etc.

Point clé : vous n’accordez pas un privilège directement à un utilisateur. Vous accordez un rôle via une ACL. Le rôle est le « paquet », l’ACL est le « où », et l’utilisateur/groupe/token est le « qui ».

Les chemins ACL sont un arbre de ressources, pas une suggestion

Pensez en scopes explicites :

• / : tout, la racine de tous les chemins.
• /dc : objets à l’échelle du datacenter (cluster, permissions, pools, inventaire stockage, etc.).
• /nodes/<node> : objets spécifiques au nœud (tâches, services, syslog, stockage local sur ce nœud).
• /vms/<vmid> : objets spécifiques VM/CT.
• /storage/<storageid> : permissions des objets de stockage.
• /pool/<poolname> : contrôle d’accès basé sur les pools, utile pour déléguer des groupes de VMs.

La « permission refusée » dans la vue Datacenter survient souvent quand vous avez donné à l’utilisateur des permissions VM sur /vms/101 mais pas la capacité de voir certains objets datacenter que le GUI interroge. Vous obtenez un accès partiel qui ressemble à un accès cassé.

La propagation contrôle l’héritage dans l’arbre

Une ACL peut propager (s’appliquer aux sous-chemins) ou non. La propagation est puissante. C’est aussi la façon dont vous accordez accidentellement l’accès à toutes les VMs alors que vous vouliez « seulement ce pool ».

Conseil opérationnel : propaguez seulement quand le chemin est déjà étroit (comme /pool/Dev), ou quand c’est vraiment intentionnel (comme /vms pour les opérateurs VM). Évitez la propagation sur / sauf si vous créez consciemment un superutilisateur.

Plusieurs ACLs se combinent

Les utilisateurs peuvent être membres de groupes, et les groupes peuvent avoir des ACLs. Un utilisateur peut aussi avoir des ACLs directs. Proxmox calcule l’union des privilèges à travers toutes les ACL correspondantes.

C’est pourquoi « retirer l’utilisateur du groupe admin » ne fonctionne parfois pas : il a encore une ACL directe quelque part que vous avez oubliée.

Le GUI est un client, pas un oracle de vérité

Le UI Proxmox est excellent, mais c’est toujours un client web appelant l’API. Quand quelque chose est refusé, il peut afficher un message générique. Votre travail est de trouver quel appel API a été refusé et quel privilège manquait.

En cas de doute, considérez le GUI comme un générateur de symptômes et utilisez le CLI pour inspecter les ACLs et les rôles.

Citation (idée paraphrasée) : Gene Kranz insistait sur le fait que la fiabilité vient de la discipline et de limites de responsabilité claires, pas des exploits héroïques.

Mode opératoire de diagnostic rapide

Voici la séquence « ne compliquez pas les choses ». Faites-la dans l’ordre. Elle vous dira généralement la pièce manquante exacte.

Premier point : confirmer l’identité et le realm

• L’utilisateur se connecte-t-il comme user@pve vs user@pam vs user@ldap ?
• Avez-vous accordé des ACLs à la mauvaise identité realm (courant avec AD/LDAP où les noms d’utilisateur se chevauchent) ?

Deuxième point : lister les ACLs qui s’appliquent

• Vérifiez les ACLs directes de l’utilisateur.
• Vérifiez l’appartenance aux groupes et les ACLs des groupes.
• Vérifiez si la propagation est activée et si le chemin de l’ACL correspond à la zone qui échoue.

Troisième point : inspecter la définition du rôle

• Le rôle inclut-il réellement le privilège que vous pensez ?
• Quelqu’un a-t-il « optimisé » un rôle en supprimant des privilèges « inutiles » et cassé le GUI ?

Quatrième point : reproduire via l’API et identifier l’endpoint refusé

• Essayez la même action avec pvesh en tant qu’utilisateur privilégié et comparez.
• Consultez les logs de tâches et les messages de permission refusée avec le contexte.

Cinquième point : vérifier la cohérence du cluster si le comportement diffère selon le node

• Si un nœud accorde l’accès et un autre le refuse, vous pouvez avoir des problèmes sur le système de fichiers du cluster ou un nœud partiellement joint.

Sixième point : ensuite seulement, changez les ACLs

Ne faites pas de changements frénétiques. Faites un changement, testez, revenez en arrière si nécessaire. Les modifications de permissions sont des changements en production.

Tâches pratiques : commandes, sorties, décisions (12+)

Toutes les tâches supposent que vous êtes sur un nœud Proxmox en tant que root ou utilisateur admin. Les commandes sont réelles. Les sorties sont représentatives. Les décisions sont ce que vous faites ensuite.

Task 1: Confirm the user identity (realm matters)

cr0x@server:~$ pveum user list
USERID               ENABLED  EXPIRE
root@pam             1
alice@pve            1
alice@ldap           1
svc-terraform@pve     1

Ce que signifie la sortie : Il existe deux utilisateurs « alice » dans des realms différents. Les ACLs sont attachées à l’identifiant complet incluant le realm.

Décision : Vérifiez lequel se connecte. Si la plainte vient d’une connexion AD, vous devez accorder alice@ldap, pas alice@pve.

Task 2: List group memberships (hidden privileges live here)

cr0x@server:~$ pveum user get alice@ldap
┌─────────┬───────────────────────────────┐
│ key     │ value                         │
╞═════════╪═══════════════════════════════╡
│ userid  │ alice@ldap                    │
├─────────┼───────────────────────────────┤
│ enable  │ 1                             │
├─────────┼───────────────────────────────┤
│ groups  │ DevOps,VM-Operators           │
└─────────┴───────────────────────────────┘

Ce que cela signifie : Alice hérite des ACLs de DevOps et VM-Operators.

Décision : Auditez ces ACLs de groupe avant de changer quoi que ce soit. La correction la plus rapide est souvent une ACL manquante sur un groupe, pas des ACLs utilisateur ponctuelles.

Task 3: Dump ACLs and search for the user or group

cr0x@server:~$ pveum acl list | egrep -i 'alice@ldap|DevOps|VM-Operators'
/pool/Dev -group VM-Operators -role PVEVMAdmin
/dc -group DevOps -role PVEAuditor

Ce que cela signifie : Les opérateurs VM ont des droits d’admin VM dans le pool Dev. DevOps a un rôle d’audit au scope datacenter.

Décision : Si Alice ne peut pas ouvrir Datacenter parce que le GUI a besoin de quelque chose au-delà de PVEAuditor, vous devez soit étendre le rôle auditor (prudemment), soit ajouter une ACL étroite pour le privilège manquant.

Task 4: Verify role contents (don’t assume)

cr0x@server:~$ pveum role show PVEAuditor
┌──────────────┬──────────────────────────────────────────────┐
│ key          │ value                                        │
╞══════════════╪══════════════════════════════════════════════╡
│ roleid       │ PVEAuditor                                   │
├──────────────┼──────────────────────────────────────────────┤
│ privileges   │ Datastore.Audit Group.Audit Mapping.Audit     │
│              │ Permissions.Modify Pool.Audit Realm.Allocate  │
│              │ SDN.Audit Sys.Audit VM.Audit                  │
└──────────────┴──────────────────────────────────────────────┘

Ce que cela signifie : Le rôle est majoritairement en lecture seule, mais notez qu’il inclut Permissions.Modify dans cet exemple (certaines environnements personnalisent cela ; les valeurs par défaut peuvent différer).

Décision : Si votre auditor peut modifier les permissions, vous avez créé un chemin silencieux d’escalade de privilèges. Corrigez la définition du rôle pour qu’elle corresponde à l’intention.

Task 5: Enumerate all privileges and spot what you’re missing

cr0x@server:~$ pveum role list
RoleID          Privileges
Administrator   *
NoAccess
PVEAdmin        Datastore.Allocate Datastore.AllocateSpace ...
PVEAuditor      Datastore.Audit Sys.Audit VM.Audit ...
PVEVMAdmin      VM.Allocate VM.Audit VM.Config.Disk VM.Config.CPU ...
PVEVMUser       VM.Audit VM.Console VM.Monitor VM.PowerMgmt

Ce que cela signifie : Les rôles sont des paquets ; Administrator est un wildcard.

Décision : Si vous êtes tenté d’utiliser Administrator, arrêtez-vous. Identifiez le rôle minimal nécessaire et appliquez-le sur le bon chemin.

Task 6: Check whether the user can list datacenter resources via API (as admin)

cr0x@server:~$ pvesh get /access/users --output-format=json-pretty | head
[
  {
    "comment": "",
    "email": "",
    "enable": 1,
    "expire": 0,
    "firstname": "",
    "groups": "DevOps;VM-Operators",
    "lastname": "",
    "userid": "alice@ldap"
  },
  ...

Ce que cela signifie : En tant qu’admin, vous pouvez récupérer les infos utilisateur. Cela confirme que l’endpoint API existe et fonctionne.

Décision : Si l’utilisateur ne peut pas charger Datacenter, déterminez quel endpoint lui est refusé. Utilisez les outils développeur du navigateur ou répliquez les appels probables (tâches suivantes).

Task 7: Quickly test if the issue is “can’t see nodes”

cr0x@server:~$ pvesh get /nodes
[
  {
    "cpu": 0.03,
    "maxcpu": 16,
    "maxmem": 68719476736,
    "mem": 12461883392,
    "node": "pve01",
    "status": "online",
    "uptime": 223948
  },
  {
    "cpu": 0.05,
    "maxcpu": 16,
    "maxmem": 68719476736,
    "mem": 18372743168,
    "node": "pve02",
    "status": "online",
    "uptime": 221402
  }
]

Ce que cela signifie : Les nœuds existent et sont accessibles pour un admin. Un utilisateur non-admin peut se voir refuser l’accès s’il lui manque Sys.Audit ou des privilèges équivalents sur /nodes ou /.

Décision : Si la barre latérale Datacenter échoue, assurez-vous que l’utilisateur a au moins des droits d’audit sur /nodes ou /dc selon ce que vous voulez qu’il voie.

Task 8: Inspect storage inventory; missing storage ACLs cause surprise denials

cr0x@server:~$ pvesh get /storage
[
  {
    "content": "images,rootdir,iso,vztmpl,backup",
    "enabled": 1,
    "shared": 1,
    "storage": "ceph-hdd"
  },
  {
    "content": "images,rootdir,backup",
    "enabled": 1,
    "shared": 0,
    "storage": "local-lvm"
  }
]

Ce que cela signifie : Les objets de stockage existent ; les panels du GUI les interrogent fréquemment.

Décision : Si un utilisateur peut gérer des VMs mais ne peut pas attacher de disques ou parcourir le stockage ISO/backup, ajoutez des ACLs sur /storage/<id> avec un rôle incluant les privilèges de datastore nécessaires.

Task 9: Show current ACLs in a readable way (full dump)

cr0x@server:~$ pveum acl list
/dc -group DevOps -role PVEAuditor
/pool/Dev -group VM-Operators -role PVEVMAdmin
/storage/ceph-hdd -group VM-Operators -role PVEDatastoreUser

Ce que cela signifie : Les permissions sont peu nombreuses et claires. Bon signe.

Décision : Si l’utilisateur se plaint d’un refus dans la vue Datacenter, vérifiez si le rôle sur /dc inclut suffisamment de droits en lecture pour les sections de l’UI dont il a besoin.

Task 10: Add a narrowly scoped ACL (example: allow monitoring only)

cr0x@server:~$ pveum acl modify /nodes -group VM-Operators -role PVEAuditor

cr0x@server:~$ pveum acl list | grep '/nodes'
/nodes -group VM-Operators -role PVEAuditor

Ce que cela signifie : Les opérateurs VM peuvent auditer le statut des nœuds sans être admins des nœuds.

Décision : Si cela corrige la visibilité Datacenter, conservez-le. Si cela expose plus que désiré, restreignez à /nodes/pve01 ou retirez et accordez plutôt seulement /dc audit plus des endpoints spécifiques (plus difficile à gérer).

Task 11: Validate pool usage; pool ACLs are the cleanest delegation mechanism

cr0x@server:~$ pvesh get /pools
[
  {
    "poolid": "Dev"
  },
  {
    "poolid": "Prod"
  }
]

Ce que cela signifie : Les pools existent.

Décision : Placez les VMs/CTs des équipes dans des pools et assignez des rôles sur /pool/<pool> avec propagation. C’est mieux que des ACLs par-VM pour la lisibilité.

Task 12: Confirm a VM is in the expected pool (or not)

cr0x@server:~$ pvesh get /pools/Dev --output-format=json-pretty | head -n 30
{
  "members": [
    {
      "id": "qemu/101",
      "node": "pve01",
      "type": "qemu",
      "vmid": 101
    },
    {
      "id": "lxc/120",
      "node": "pve02",
      "type": "lxc",
      "vmid": 120
    }
  ],
  "poolid": "Dev"
}

Ce que cela signifie : La VM 101 est dans le pool Dev, donc les ACLs /pool/Dev s’appliquent.

Décision : Si un utilisateur ne peut pas gérer « sa » VM, vérifiez d’abord si la VM est dans le pool attendu avant d’éditer des ACLs.

Task 13: Detect role drift (custom roles are where good intentions go to die)

cr0x@server:~$ pveum role show VMOperatorCustom
roleid: VMOperatorCustom
privileges: VM.Audit VM.Console VM.PowerMgmt VM.Snapshot

Ce que cela signifie : Le rôle personnalisé manque VM.Config.Disk et Datastore.AllocateSpace, donc les opérations sur les disques peuvent échouer.

Décision : Décidez si les opérateurs VM doivent gérer les disques. Si oui, mettez à jour le rôle ; si non, documentez cette limitation et fournissez une procédure de demande de changement de stockage.

Task 14: Audit API tokens (they often outlive the humans who created them)

cr0x@server:~$ pveum user token list svc-terraform@pve
tokenid       expire  privsep
tf-ci         0       1
tf-prod       0       1

Ce que cela signifie : Des tokens existent et utilisent la séparation des privilèges (privsep=1), ce qui est souhaitable. Cela signifie que les permissions du token sont séparées de celles de l’utilisateur.

Décision : Assurez-vous que chaque token ait des ACLs explicites sur les chemins minimaux nécessaires. Ne comptez pas sur des permissions larges de l’utilisateur.

Task 15: Check cluster health when permissions seem inconsistent across nodes

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             corp-pve
Config Version:   27
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 12:40:11 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Ce que cela signifie : Le cluster a le quorum ; la config (y compris les permissions) devrait être cohérente.

Décision : Si vous êtes en quorum et voyez toujours des comportements divergents, suspectez un cache navigateur, des chemins d’authentification différents, ou des problèmes locaux au nœud comme une dérive horaire affectant les tokens.

Conception des rôles : quoi créer, quoi bannir, et quoi garder ennuyeux

La conception RBAC est là où les boutiques Proxmox deviennent propres ou hantées. L’objectif n’est pas la perfection. L’objectif est : des permissions prévisibles que vous pouvez expliquer à 03h00.

Principe 1 : Préférez les ACLs de groupe aux ACLs utilisateur

Les ACLs utilisateur se multiplient comme une rumeur : rapides, désordonnées et difficiles à rétracter. Utilisez des groupes pour les humains. Utilisez des tokens pour l’automatisation. Utilisez les ACLs utilisateur directes uniquement pour l’accès d’urgence ou temporaire avec une date d’expiration que vous respectez réellement.

Principe 2 : Utilisez des pools pour la délégation

Si vous n’utilisez pas les pools, vous gérez les ACLs de la manière la plus difficile. Les pools vous donnent une poignée stable pour « l’équipe possède ces VMs/CTs ». Attribuez des rôles sur /pool/TeamX avec propagation. Déplacez les workloads entre pools quand la propriété change. C’est la séparation propre.

Principe 3 : Séparez « peut opérer des VMs » de « peut modifier l’infrastructure »

Les opérateurs VM devraient pouvoir :

• Démarrer/arrêter/redémarrer
• Accéder à la console
• Voir la configuration et les métriques
• Faire des snapshots (peut-être)

Ils ne devraient généralement pas pouvoir :

• Ajouter de nouveaux backends de stockage
• Éditer le réseau du cluster
• Modifier les permissions
• Gérer les nœuds/services

Cela paraît évident jusqu’à ce que vous réalisiez à quelle fréquence des gens accordent des privilèges niveau nœud juste pour faire disparaître une erreur UI.

Principe 4 : Créez un petit nombre de rôles personnalisés, et traitez-les comme du code

Les rôles par défaut existent pour une raison. Les rôles personnalisés sont acceptables, mais chaque rôle personnalisé devrait avoir :

• une phrase d’objectif (« Opérateur VM avec droits d’attachement disque dans Dev seulement »)
• un chemin de scope clairement défini où il est autorisé
• un propriétaire (équipe) responsable de la révision trimestrielle

Principe 5 : Ne « réparez » pas une permission refusée en élargissant le scope

Si l’utilisateur reçoit un refus à Datacenter, la correction n’est généralement pas « Administrator sur /dc ». C’est souvent :

• mauvaise identité realm
• ACL sur le mauvais chemin
• rôle manquant d’un privilège requis par l’UI
• mauvaise appartenance au pool
• ACL stockage manquante

Blague #2 : Le moyen le plus rapide de résoudre un ticket RBAC est de supprimer le RBAC. Les équipes sécurité appellent ça « développement de carrière ».

Trois micro-histoires d’entreprise du terrain

Micro-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox propre pour des services internes : runners CI, caches de build, quelques environnements applicatifs « temporaires » devenus permanents parce que personne n’aime refaire le travail. Un ingénieur plateforme a créé un groupe « VM Admin » et appliqué PVEVMAdmin sur /vms, en supposant que cela suffirait pour les opérations quotidiennes.

Puis un développeur a ouvert un ticket : « Vue Datacenter cassée, permission refusée. » L’ingénieur a ouvert le GUI en tant que le développeur et a vu la bannière d’erreur. L’hypothèse immédiate fut que le rôle était incorrect, donc ils ont escaladé : ils ont ajouté PVEAdmin sur /dc au groupe. Erreur disparue. Ticket clos. Tout le monde content.

Une semaine plus tard, les sauvegardes ont commencé à échouer — pas parce qu’elles ne pouvaient pas être lancées, mais parce que quelqu’un a « aidé » en éditant la configuration du stockage de backups en debugant un autre problème. Ils avaient l’accès parce que PVEAdmin sur /dc inclut de larges privilèges datacenter. La configuration résultante était suffisamment valide pour être sauvegardée, mais suffisamment erronée pour casser les restaurations. La faille n’est apparue qu’au test de restauration.

La cause racine n’était pas la malveillance. C’était la mauvaise hypothèse : que la vue Datacenter requiert des privilèges admin datacenter. En réalité, elle avait besoin d’une visibilité d’audit sur les nœuds et le stockage pour les panels que l’UI chargeait. La correction correcte aurait été étroite : accorder PVEAuditor sur /nodes et un rôle datastore-user sur des chemins de stockage spécifiques, ou ajuster un rôle personnalisé avec seulement les privilèges d’audit requis.

La remédiation fut ennuyeuse : retirer l’ACL large, ajouter des ACLs précises, et documenter « les erreurs GUI sont des erreurs d’endpoint API, pas des échecs de rôle ». Cela a réduit leur rayon d’impact immédiatement.

Micro-histoire 2 : L’optimisation qui s’est retournée contre eux

Une grande équipe d’entreprise a décidé qu’ils avaient « trop de rôles ». Ils essayaient de standardiser l’accès entre virtualisation, Kubernetes et bare metal. Quelqu’un a proposé une simplification : créer un rôle Proxmox personnalisé unique appelé OpsStandard pour couvrir 95% des besoins. Ils ont extrait des privilèges de plusieurs rôles existants et supprimé tout ce qui « semblait risqué ».

Au début, ça a fonctionné. Moins de noms de rôles, moins de lignes ACL. Puis des bizarreries ont commencé : migrations de VM échouant pour certains utilisateurs, opérations de snapshot refusées par intermittence, et le GUI affichant parfois des listes de stockage vides. Chaque symptôme apparaissait dans différentes zones du produit, ce qui faisait penser à un bug Proxmox.

Le vrai problème était l’« optimisation ». Ils ont retiré quelques privilèges qui semblaient secondaires, mais dont l’UI et les workflows dépendaient. Le rôle permettait toujours d’allumer des VMs, donc les gens pensaient que tout allait bien. Ce n’était pas le cas. Les privilèges refusés étaient requis pour des requêtes accessoires et des mises à jour d’état.

Ils se sont retrouvés avec un rôle à la fois trop large (appliqué sur / pour éviter les cas limites) et trop étroit (manquant des privilèges clés). C’est un état particulier : il génère de l’acharnement sans réellement appliquer le moindre privilège.

La correction a été de défaire la simplification. Ils sont revenus à un petit ensemble de rôles alignés sur les responsabilités, et ils ont limité le scope en utilisant des pools et des chemins de stockage plutôt que « un rôle pour tous ». Le design final avait plus de lignes ACL, mais moins d’incidents.

Micro-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe proche des finances gérait Proxmox pour des workloads sensibles en conformité. Ils avaient une habitude que tout le monde moquait : des revues trimestrielles d’accès. Pas un exercice de feuille de calcul — une vraie revue des groupes, rôles et chemins ACL, avec une seconde personne qui vérifie.

Lors d’une revue ils ont remarqué quelque chose de subtil : un ancien compte de sous-traitant était désactivé, mais son token API existait toujours. Le token avait ses propres ACLs parce que la séparation des privilèges était activée. Il avait aussi accès à /storage/backup-nfs avec un rôle permettant la lecture des backups.

Rien de mauvais ne s’était encore produit. C’est justement le point. Ils ont révoqué le token, retiré l’ACL et fait tourner quelques secrets. Plus tard dans l’année, un autre système a été compromis et des attaquants ont sondé les APIs internes. Le token Proxmox aurait été un chemin facile pour voler des backups s’il avait existé encore.

Ce qui les a sauvés n’était pas un outil malin. C’était la pratique ennuyeuse : traiter les tokens comme des identifiants de production, les réviser et les supprimer quand le service ou la personne n’existe plus.

Ils gardaient aussi leur conception RBAC douloureusement simple : pools pour la propriété, groupes séparés pour audit vs opération, et aucun rôle personnalisé sauf si une exigence écrite l’exigeait. Ainsi, quand ils voyaient des erreurs « permission refusée », le diagnostic était rapide parce que le système était lisible.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “Permission denied” when clicking Datacenter, but VM console works

Cause racine : L’utilisateur a des privilèges au niveau VM (/vms/<id> ou /pool/<pool>) mais manque des droits d’audit pour les nœuds / stockage interrogés par l’UI Datacenter.

Correction : Ajoutez un rôle d’audit sur /nodes (ou /dc si approprié) et un rôle datastore audit/user sur les /storage/<id> requis. Gardez-le en lecture seule sauf si vous voulez plus.

2) Symptom: Works for alice@pve but not for alice@ldap

Cause racine : ACLs accordées à la mauvaise identité realm.

Correction : Accordez les ACLs au bon user@realm. Envisagez de désactiver les comptes locaux shadows pour réduire la confusion.

3) Symptom: User can start/stop VMs but cannot attach ISO images

Cause racine : Privilèges datastore manquants sur le chemin de stockage ISO (/storage/<id>), pas un problème de privilège VM.

Correction : Ajoutez un rôle datastore user/auditor sur ce stockage, ou déplacez les ISOs vers un stockage avec des ACLs appropriées.

4) Symptom: Backup job fails with permission errors only when run by automation

Cause racine : Le token API a la séparation des privilèges activée et n’hérite pas des ACLs de l’utilisateur ; le token manque ses propres ACLs.

Correction : Ajoutez des ACLs pour l’identité du token sur les chemins requis, ou désactivez la séparation des privilèges seulement si vous acceptez le couplage (en général, vous ne devriez pas).

5) Symptom: Datacenter → Permissions page is inaccessible to “auditors”

Cause racine : Le rôle auditor manque des privilèges d’audit pertinents pour les objets permissions, ou vous l’avez restreint intentionnellement et l’UI refuse correctement.

Correction : Décidez de l’intention. S’ils doivent voir les permissions, ajoutez le privilège d’audit nécessaire via la mise à jour du rôle. Sinon, cessez de promettre l’accès à cette page.

6) Symptom: User sees some VMs but not others in the same team

Cause racine : Les VMs ne sont pas assignées de manière cohérente au pool, ou les ACLs par-VM ont divergé avec le temps.

Correction : Normalisez avec des pools. Déplacez les VMs dans le pool correct ; retirez les ACLs par-VM sauf exception documentée.

7) Symptom: Permissions appear correct, but user still gets denied after changes

Cause racine : Session/token mis en cache du navigateur ; l’utilisateur est connecté sous un autre realm ; ou vous avez changé l’appartenance au groupe mais la session n’a pas été rafraîchie.

Correction : Demandez à l’utilisateur de se déconnecter/se reconnecter ; confirmez le realm dans le label utilisateur en haut à droite ; revérifiez via le CLI et assurez-vous d’avoir modifié la bonne identité.

8) Symptom: Different nodes behave differently for the same user

Cause racine : Incohérence du cluster (problèmes de quorum, nœud pas complètement joint) ou différences d’intégration d’authentification locales au nœud.

Correction : Vérifiez pvecm status, assurez-vous du quorum ; vérifiez la configuration des realms sur tous les nœuds ; rétablissez la santé du système de fichiers du cluster avant de toucher aux ACLs.

Listes de vérification / plan pas-à-pas

Checklist A: Build RBAC correctly for a team (human users)

1. Créez (ou utilisez) un realm d’auth qui correspond à l’identité corporative (LDAP/AD/OIDC). Ne créez pas d’utilisateurs locaux en double sauf si c’est intentionnel.
2. Créez des groupes qui correspondent aux responsabilités, pas à l’organigramme : VM-Operators, VM-Auditors, Storage-Operators.
3. Créez des pools par équipe ou environnement : Dev, Prod, Analytics.
4. Placez les VMs/CTs dans des pools comme source de vérité pour la propriété.
5. Attribuez des rôles sur /pool/<pool> avec propagation :
   • PVEVMUser ou PVEVMAdmin selon s’ils peuvent changer la config.
6. Accordez PVEAuditor sur /nodes s’ils doivent voir le statut des nœuds dans le GUI.
7. Accordez des rôles datastore sur des chemins /storage/<id> spécifiques pour l’accès ISO/backup si nécessaire.
8. Documentez ce qu’ils ne peuvent pas faire (snapshots ? redimensionnement disque ? migrations ?). Moins de surprises = moins de demandes « rendez-les admin ».

Checklist B: Fix a live “Datacenter permission denied” ticket without making it worse

1. Confirmez le realm de l’utilisateur et l’identifiant exact (user@realm).
2. Listez les groupes de l’utilisateur et les ACLs existantes.
3. Identifiez la page/action qui échoue. Demandez le chemin exact du clic et l’heure.
4. Vérifiez si l’utilisateur peut :
   • lister les nœuds (audit)
   • lister le stockage (audit)
   • voir le pool et ses membres
5. Si manquant, ajoutez les ACLs d’audit minimales sur le bon chemin.
6. Re-testez avec l’utilisateur. Si c’est fixé, arrêtez. N’« améliorez » pas davantage sur le vif.
7. Si ce n’est pas résolu, identifiez l’endpoint refusé en inspectant les logs de tâches ou en reproduisant via des appels API.
8. En dernier recours, accordez temporairement un rôle plus large avec une limite de temps et un plan de rollback.

Checklist C: Token-based automation done safely

1. Créez un utilisateur de service dédié par domaine d’automatisation (ex. svc-terraform@pve).
2. Créez des tokens par environnement (tf-dev, tf-prod) pour pouvoir révoquer chirurgicalement.
3. Gardez privsep=1 et assignez des ACLs explicites aux tokens. Ne vous reposez pas sur les ACLs de l’utilisateur.
4. Donnez l’accès au scope pool et au scope stockage requis, pas à /.
5. Révisez les tokens trimestriellement et supprimez ceux qui ne sont plus utilisés. Faites tourner les identifiants lors de changements de personnel ou de propriété des pipelines.

FAQ (8+)

1) Pourquoi Proxmox affiche « permission refusée » dans Datacenter alors que je veux seulement l’accès VM ?

Parce que le GUI charge des données à l’échelle du datacenter et du nœud pour peupler la barre latérale, les tableaux de bord et les panneaux d’état. Les ACLs limitées aux VMs ne couvrent pas forcément ces appels API.

2) Dois-je simplement accorder PVEAuditor sur / pour que tout le monde voie tout ?

Non. Accordez des droits d’audit sur /nodes et /dc seulement si nécessaire, et considérez ce que « tout voir » signifie dans votre organisation. La visibilité reste un accès.

3) Quelle est la manière la plus sûre de donner à une équipe l’accès à « leurs » VMs ?

Utilisez les pools. Placez leurs VMs/CTs dans /pool/Team et assignez un rôle centré VM là-bas avec propagation. C’est propre et réversible.

4) Pourquoi mon opérateur VM ne peut-il pas attacher de disques ou monter des ISOs ?

Les opérations disque/ISO touchent souvent des objets de stockage. Vous avez besoin de privilèges appropriés sur /storage/<id> en plus des privilèges VM.

5) Les tokens API héritent-ils des permissions de l’utilisateur ?

Pas si la séparation des privilèges est activée pour le token (privsep=1). Dans ce cas, les tokens ont besoin de leurs propres ACLs. C’est généralement ce que vous voulez pour l’automatisation.

6) J’ai accordé le bon rôle, mais ça affiche toujours refusé. Que faire ?

Confirmez que vous l’avez accordé à la bonne identité (user@realm), sur le bon chemin, avec la propagation si nécessaire. Ensuite, demandez à l’utilisateur de se déconnecter/se reconnecter pour rafraîchir la session.

7) Est-il acceptable de personnaliser les rôles par défaut ?

Vous pouvez, mais traitez cela comme modifier une bibliothèque de production : versionnez mentalement, documentez, et attendez des surprises. Préférez créer un nouveau rôle personnalisé pour que les défauts restent prévisibles.

8) Comment stopper l’expansion des privilèges au fil du temps ?

Utilisez des ACLs basées sur les groupes, un verrouillage par pools, et des revues trimestrielles des ACLs et tokens. Supprimez les ACLs utilisateur ponctuelles sauf s’il y a une exception écrite.

9) Pourquoi ça fonctionne sur un nœud et pas sur un autre ?

Soit l’état du cluster n’est pas cohérent (distribution de config/quorum), soit la configuration du realm d’auth diffère par nœud, soit l’utilisateur s’authentifie différemment. Rétablissez d’abord la cohérence.

10) Quel est le « bon » emplacement pour assigner les permissions : /dc ou / ?

Presque jamais /. Utilisez /dc pour les besoins de lecture à l’échelle du datacenter (et seulement pour des rôles admins de confiance pour l’écriture). Utilisez pools, nodes et chemins de stockage pour tout le reste.

Conclusion : prochaines étapes à faire aujourd’hui

Les erreurs « permission refusée » de Proxmox dans Datacenter ne sont pas aléatoires. Elles indiquent que votre histoire RBAC ne correspond pas à la manière dont le GUI et l’API accèdent réellement aux ressources.

Faites ces prochaines étapes :

1. Sélectionnez un utilisateur en difficulté et cartographiez identité → groupes → chemins ACL → rôles. Écrivez-le en quatre lignes. Si vous ne pouvez pas, votre RBAC est déjà trop astucieux.
2. Déplacez les workloads d’équipe dans des pools et arrêtez les ACLs par-VM façon whack-a-mole.
3. Ajoutez un accès d’audit minimal pour nœuds/stockage seulement quand c’est nécessaire pour la visibilité. N’utilisez pas « accès Datacenter » comme excuse pour un admin datacenter.
4. Inventoriez les tokens API, confirmez privsep=1, et assurez-vous que chaque token a des ACLs explicites et étroites.
5. Planifiez une revue RBAC trimestrielle. Oui, c’est ennuyeux. C’est pour ça que ça marche.