Migrar a Proxmox: los permisos no viajan, y el rol que suena a «usuario» abre la consola

De una migración de vSphere a Proxmox no viaja ni una línea de la tabla de permisos, y como las dos tablas se parecen mucho en la forma, casi nadie reconstruye la suya: la copia de memoria, por el nombre de los roles. Los discos llegan, la configuración de cada máquina llega y las redes llegan con trabajo. Los permisos se rehacen a ojo.

Llevamos Proxmox VE en producción desde las ramas 3.x, operamos clústeres con almacenamiento Ceph en varios datacenters y hemos migrado empresas desde VMware — también hemos recomendado quedarse en VMware cuando tenía sentido. Este post no va de rendimiento ni de licencias: va de la media hora que casi nadie pone en el plan de corte, y de un rol cuyo nombre engaña.

Las dos tablas se parecen demasiado

La documentación de vSphere lo dice así: «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 dice que una regla de acceso «can be represented as a triple of (path, user, role), (path, group, role) or (path, token, role)». Un objeto o una ruta, un usuario o un grupo, un rol, y propagación hacia abajo activada por defecto.

Cuando dos modelos comparten la forma, el cerebro asume que comparten el contenido. Lo que acaba viajando es la sensación de haberlo entendido.

El rol que suena a «usuario»

Llegas de vCenter buscando el rol más inofensivo de la lista para dárselo a quien solo tiene que usar su máquina. Encuentras PVEVMUser. El nombre es tranquilizador. La definición de la documentación de Proxmox, literal, es: «view, backup, configure CD-ROM, VM console, VM power management».

Tres de esas cinco capacidades son consola, CD-ROM y encendido/apagado. Juntas describen a alguien sentado delante de la máquina, con la bandeja de discos abierta y el botón de reinicio a mano. El privilegio VM.Console está documentado en una línea —«console access to VM»— y esa línea tiene una propiedad que conviene mirar despacio: la consola no pasa por la red del invitado. No hay IP de la máquina que alcanzar, ni cortafuegos suyo que cruzar, ni RDP o SSH publicados en ninguna parte. Basta con llegar a la interfaz de gestión de Proxmox, que es otra puerta y suele vivir en otro segmento. Se entra por el hipervisor y se sale en la pantalla del invitado.

La consola te da la pantalla y el teclado: para iniciar sesión en el sistema operativo sigues necesitando sus credenciales. Lo que hay que mirar es la combinación. Que el mismo rol traiga consola, cambio de CD-ROM y encendido deja una pregunta abierta que solo tu instalación puede responder: ¿a qué almacenamiento llega ese usuario para elegir una ISO, y están cifrados los discos de esas máquinas? Si la respuesta a la primera es «al mismo donde están las ISO» y la de la segunda es «no», ese rol no es de usuario. Si ninguna de las dos se cumple, tampoco pasa nada grave — pero entonces es una decisión tomada, y no un nombre que sonaba bien.

Queda una cuarta capacidad del mismo rol, y es la que menos ruido hace: backup, documentada como «backup/restore VMs». Ya contamos en agosto, leyendo el código, que la marca «protected» de una copia no es un candado. Quien puede hacer y restaurar copias tiene sobre tus puntos de restauración bastante más mando del que sugiere la palabra «usuario».

La tabla de equivalencias, con sus huecos

La regla de herencia que resta

De toda la página de gestión de usuarios, la frase que más caro sale es esta: «Permissions for individual users always replace group permissions». Reemplazan. No se suman.

Quien viene de Active Directory trae el reflejo contrario incorporado desde hace veinte años: las pertenencias a grupos acumulan. Aquí, si el grupo sistemas tiene PVEVMAdmin en /vms y a una persona de ese grupo le das, además, una entrada individual en /vms/120 «para que pueda hacer también una cosa concreta», en esa ruta esa persona pasa a tener solo lo que diga su entrada individual. Le has dado permiso y le has quitado permisos en el mismo gesto. La misma página añade dos frases más del mismo tipo: «Permissions on deeper levels replace those inherited from an upper level» y «NoAccess cancels all other roles on a given path».

Nada de esto es un defecto. Es un modelo coherente y está escrito. Pero es un modelo que castiga el atajo —la entrada individual puesta deprisa un viernes— y el atajo es exactamente lo que se hace la semana después de un corte, cuando alguien llama porque no puede hacer algo y hay prisa.

Los privilegios que entran dentro de la máquina

Durante la migración quitas las VMware Tools y pones el agente de QEMU: es parte del guion, y es lo correcto. Lo que ese agente abre al otro lado es una familia de privilegios que en el mundo de vCenter no tiene un equivalente mental directo. Las descripciones de la documentación de Proxmox son de una claridad que agradece leerse entera:

Leer y escribir ficheros dentro del invitado, desde el panel del hipervisor, sin tocar la red del invitado. Y que esto esté partido en cinco privilegios distintos es una virtud del modelo. Que exista FileRead separado de FileWrite y ambos separados de Unrestricted permite dar a un sistema de inventario justo lo que necesita y nada más. El granulado está bien. Lo que falla es que casi nadie llega a esta página. Se reparte PVEVMAdmin —«fully administer VMs»— y a otra cosa.

root@pam no es el administrador de vCenter

La documentación lo dice sin rodeos: «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». Esa cuenta es el root de Linux del nodo. Su contraseña vive en cada máquina. Y las palabras que importan de esa frase son «cannot be deleted», porque la política de identidad que acabas de escribir con tanto cuidado tiene, por diseño, una puerta que no puedes borrar y que no está en tu directorio. Borrarla, no; lo que sí dice la otra mitad de la frase es que «attributes can still be changed»: ponerle segundo factor y sacarla del día a día está en tu mano, y es lo primero que hacemos.

Es el mismo patrón que ya hemos contado dos veces desde otros ángulos: la configuración de red la guarda cada nodo, no el clúster, y una clave de Ceph no se refresca reiniciando la VM. En Proxmox hay cosas que viven en la máquina y no en el conjunto, y todas ellas comparten el mismo síntoma: nadie las echa de menos hasta que hacen falta.

Cuatro comandos para el lunes siguiente

Todo esto se audita desde la línea de comandos en menos tiempo del que cuesta discutirlo en una reunión. Cuatro órdenes, y el resultado pegado en el documento de entrega de la migración, con la fecha al lado:

La primera devuelve la tabla entera de accesos: ruta, quién y con qué rol. La segunda enseña qué lleva dentro cada rol de verdad, que es lo único que apaga la discusión sobre nombres. La tercera, quién existe y en qué realm. La cuarta, los tokens de una persona — y ahí la casilla que hay que mirar es la separación de privilegios, --privsep, que viene activada por defecto en los tokens nuevos y cuyo efecto la documentación describe así: «Its effective permissions are calculated by intersecting user and token permissions». Un token sin separación tiene todo lo del usuario que lo creó, y los tokens son lo que acaba pegado en un fichero de configuración de un sistema de copias.

Y dos preguntas que no responde ningún comando. Quién conoce la contraseña de root@pam de cada nodo y dónde está escrita. Y qué pasa el día que esa persona se va.

Los límites de lo que acabamos de decir

No decimos que el modelo de permisos de Proxmox sea peor que el de vCenter. En la parte del agente invitado es claramente más fino, y la composición exacta de cada rol predefinido puede cambiar entre versiones: la página que manda es la de tu versión, leída el día que diseñas los roles, no este post. Tampoco decimos que PVEVMUser esté mal hecho; está documentado con una precisión que pocos fabricantes alcanzan, y el que no lo lee somos nosotros.

El conflicto de interés, por delante: diseñar roles y auditar accesos es trabajo que facturamos. Si en tu empresa alguien ya tiene pegada la salida de pveum acl list en el documento de entrega, con fecha y con un nombre al lado de cada línea, esta parte ya la tenéis resuelta y no nos necesitáis para ella.

Fuentes (verificadas el 4 de octubre de 2026): la definición de la ACL como triple (ruta, usuario/grupo/token, rol), la bandera propagate activada por defecto, las reglas de herencia («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»), los realms disponibles, la frase sobre root@pam como administrador sin límites que no se puede borrar, la lista de roles predefinidos con su descripción (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»), las descripciones literales de VM.Console y de la familia VM.GuestAgent.*, y la separación de privilegios de los tokens de API — User Management, wiki de Proxmox VE y capítulo pveum del manual de administración. La sintaxis de pveum acl list, pveum role list, pveum user list, pveum user token list y la opción --privsep (por defecto 1) — página de manual de pveum. La definición de permiso en vCenter Server y la existencia de roles de sistema y de ejemplo — vSphere Security, documentación de VMware.