Migrar a Proxmox: els permisos no viatgen, i el rol que sona a «usuari» obre la consola

D'una migració de vSphere a Proxmox no hi viatja ni una línia de la taula de permisos, i com que les dues taules s'assemblen molt en la forma, gairebé ningú no reconstrueix la seva: la copia de memòria, pel nom dels rols. Els discos hi arriben, la configuració de cada màquina hi arriba i les xarxes hi arriben amb feina. Els permisos es refan a ull.

Portem Proxmox VE en producció des de les branques 3.x, operem clústers amb emmagatzematge Ceph en diversos datacenters i hem migrat empreses des de VMware — també hem recomanat quedar-se a VMware quan tenia sentit. Aquest article no va de rendiment ni de llicències: va de la mitja hora que gairebé ningú no posa al pla de tall, i d'un rol el nom del qual enganya.

Les dues taules s'assemblen massa

La documentació de vSphere ho diu així: «A permission is set on an object in the vCenter Server object hierarchy. Each permission associates the object with a group or user and the group's or user's access role». La de Proxmox diu que una regla d'accés «can be represented as a triple of (path, user, role), (path, group, role) or (path, token, role)». Un objecte o una ruta, un usuari o un grup, un rol, i propagació cap avall activada per defecte.

Quan dos models comparteixen la forma, el cervell assumeix que comparteixen el contingut. El que acaba viatjant és la sensació d'haver-lo entès.

El rol que sona a «usuari»

Arribes de vCenter buscant el rol més inofensiu de la llista per donar-lo a qui només ha d'utilitzar la seva màquina. Trobes PVEVMUser. El nom és tranquil·litzador. La definició de la documentació de Proxmox, literal, és: «view, backup, configure CD-ROM, VM console, VM power management».

Tres d'aquelles cinc capacitats són consola, CD-ROM i engegada/aturada. Juntes descriuen algú assegut davant de la màquina, amb la safata de discos oberta i el botó de reinici a mà. El privilegi VM.Console està documentat en una línia —«console access to VM»— i aquella línia té una propietat que convé mirar a poc a poc: la consola no passa per la xarxa del convidat. No hi ha IP de la màquina que calgui abastar, ni tallafocs seu que calgui creuar, ni RDP o SSH publicats enlloc. N'hi ha prou d'arribar a la interfície de gestió de Proxmox, que és una altra porta i sol viure en un altre segment. S'entra per l'hipervisor i se surt a la pantalla del convidat.

La consola et dona la pantalla i el teclat: per iniciar sessió al sistema operatiu continues necessitant-ne les credencials. El que cal mirar és la combinació. Que el mateix rol porti consola, canvi de CD-ROM i engegada deixa una pregunta oberta que només la teva instal·lació pot respondre: a quin emmagatzematge arriba aquell usuari per triar una ISO, i estan xifrats els discos d'aquelles màquines? Si la resposta a la primera és «al mateix on hi ha les ISO» i la de la segona és «no», aquell rol no és d'usuari. Si cap de les dues no es compleix, tampoc no passa res greu — però llavors és una decisió presa, i no un nom que sonava bé.

Queda una quarta capacitat del mateix rol, i és la que fa menys soroll: backup, documentada com a «backup/restore VMs». Ja vam explicar a l'agost, llegint el codi, que la marca «protected» d'una còpia no és cap cadenat. Qui pot fer i restaurar còpies té sobre els teus punts de restauració força més comandament del que suggereix la paraula «usuari».

La taula d'equivalències, amb els seus buits

La regla d'herència que resta

De tota la pàgina de gestió d'usuaris, la frase que surt més cara és aquesta: «Permissions for individual users always replace group permissions». Reemplacen. No se sumen.

Qui ve d'Active Directory porta el reflex contrari incorporat des de fa vint anys: les pertinences a grups acumulen. Aquí, si el grup sistemes té PVEVMAdmin a /vms i a una persona d'aquell grup li dones, a més, una entrada individual a /vms/120 «perquè pugui fer també una cosa concreta», en aquella ruta aquella persona passa a tenir només el que digui la seva entrada individual. Li has donat permís i li has tret permisos en el mateix gest. La mateixa pàgina hi afegeix dues frases més del mateix tipus: «Permissions on deeper levels replace those inherited from an upper level» i «NoAccess cancels all other roles on a given path».

Res d'això no és un defecte. És un model coherent i està escrit. Però és un model que castiga la drecera —l'entrada individual posada de pressa un divendres— i la drecera és exactament el que es fa la setmana després d'un tall, quan algú truca perquè no pot fer una cosa i hi ha pressa.

Els privilegis que entren dins de la màquina

Durant la migració treus les VMware Tools i poses l'agent de QEMU: és part del guió, i és el correcte. El que aquell agent obre a l'altre costat és una família de privilegis que al món de vCenter no té un equivalent mental directe. Les descripcions de la documentació de Proxmox són d'una claredat que s'agraeix llegir sencera:

Llegir i escriure fitxers dins del convidat, des del panell de l'hipervisor, sense tocar la xarxa del convidat. I que això estigui partit en cinc privilegis diferents és una virtut del model. Que existeixi FileRead separat de FileWrite i tots dos separats d'Unrestricted permet donar a un sistema d'inventari just el que necessita i res més. El granulat està bé. El que falla és que gairebé ningú no arriba a aquesta pàgina. Es reparteix PVEVMAdmin —«fully administer VMs»— i a una altra cosa.

root@pam no és l'administrador de vCenter

La documentació ho diu sense embuts: «The system's root user can always log in via the Linux PAM realm and is an unconfined administrator. This user cannot be deleted, but attributes can still be changed». Aquell compte és el root de Linux del node. La seva contrasenya viu a cada màquina. I les paraules que importen d'aquella frase són «cannot be deleted», perquè la política d'identitat que acabes d'escriure amb tanta cura té, per disseny, una porta que no pots esborrar i que no és al teu directori. Esborrar-la, no; el que sí que diu l'altra meitat de la frase és que «attributes can still be changed»: posar-li segon factor i treure-la del dia a dia és a la teva mà, i és el primer que fem.

És el mateix patró que ja hem explicat dues vegades des d'altres angles: la configuració de xarxa la guarda cada node, no el clúster, i una clau de Ceph no es refresca reiniciant la VM. A Proxmox hi ha coses que viuen a la màquina i no al conjunt, i totes comparteixen el mateix símptoma: ningú no les troba a faltar fins que fan falta.

Quatre ordres per al dilluns següent

Tot això s'audita des de la línia d'ordres en menys temps del que costa discutir-ho en una reunió. Quatre ordres, i el resultat enganxat al document de lliurament de la migració, amb la data al costat:

La primera retorna la taula sencera d'accessos: ruta, qui i amb quin rol. La segona ensenya què porta dins cada rol de debò, que és l'única cosa que apaga la discussió sobre noms. La tercera, qui existeix i en quin realm. La quarta, els tokens d'una persona — i allà la casella que cal mirar és la separació de privilegis, --privsep, que ve activada per defecte als tokens nous i l'efecte de la qual la documentació descriu així: «Its effective permissions are calculated by intersecting user and token permissions». Un token sense separació té tot el de l'usuari que el va crear, i els tokens són el que acaba enganxat en un fitxer de configuració d'un sistema de còpies.

I dues preguntes que no respon cap ordre. Qui coneix la contrasenya de root@pam de cada node i on està escrita. I què passa el dia que aquella persona se'n va.

Els límits del que acabem de dir

No diem que el model de permisos de Proxmox sigui pitjor que el de vCenter. A la part de l'agent convidat és clarament més fi, i la composició exacta de cada rol predefinit pot canviar entre versions: la pàgina que mana és la de la teva versió, llegida el dia que dissenyes els rols, no aquest article. Tampoc no diem que PVEVMUser estigui mal fet; està documentat amb una precisió que pocs fabricants assoleixen, i el qui no el llegeix som nosaltres.

El conflicte d'interès, per davant: dissenyar rols i auditar accessos és feina que facturem. Si a la teva empresa algú ja té enganxada la sortida de pveum acl list al document de lliurament, amb data i amb un nom al costat de cada línia, aquesta part ja la teniu resolta i no ens necessiteu per a ella.

Fonts (verificades el 4 d'octubre del 2026): la definició de l'ACL com a triple (ruta, usuari/grup/token, rol), la bandera propagate activada per defecte, les regles d'herència («Permissions for individual users always replace group permissions», «Permissions on deeper levels replace those inherited from an upper level», «NoAccess cancels all other roles on a given path»), els realms disponibles, la frase sobre root@pam com a administrador sense límits que no es pot esborrar, la llista de rols predefinits amb la seva descripció (PVEVMUser: «view, backup, configure CD-ROM, VM console, VM power management»; PVEVMAdmin: «fully administer VMs»; PVEAdmin: «can do most tasks, but has no rights to modify system settings or permissions»), les descripcions literals de VM.Console i de la família VM.GuestAgent.*, i la separació de privilegis dels tokens d'API — User Management, wiki de Proxmox VE i capítol pveum del manual d'administració. La sintaxi de pveum acl list, pveum role list, pveum user list, pveum user token list i l'opció --privsep (per defecte 1) — pàgina de manual del pveum. La definició de permís a vCenter Server i l'existència de rols de sistema i d'exemple — vSphere Security, documentació de VMware.