Proxmox “Permiso denegado” en Datacenter: Roles y ACL correctos

“Permiso denegado” en la vista Datacenter de Proxmox es el tipo de mensaje que parece una molestia menor —hasta que bloquea copias de seguridad, rompe la automatización y convierte tu turno de guardia en una danza interpretativa con rutas de ACL.

Esto no es un problema místico. Los permisos de Proxmox son deterministas. El dolor viene de los humanos: suposiciones erróneas sobre la herencia de ACL, confusión entre las rutas Datacenter vs nodo vs VM, y definiciones de roles que crecen como moho en un sótano.

El modelo mental de permisos que realmente funciona

Los permisos de Proxmox no son difíciles. Solo están en capas. Si no mantienes las capas claras, “arreglarás” el acceso poniendo Administrator en un usuario en / y lo darás por terminado. Eso funciona igual que arreglar un grifo que gotea cortando el suministro de agua de la ciudad.

Este es el modelo que necesitas:

• Identidad: usuario, grupo o token de API. Almacenado en un realm (PAM, PVE, LDAP/AD, OpenID, etc.).
• Rol: un paquete nombrado de privilegios (por ejemplo, PVEVMAdmin, PVEAuditor).
• ACL: vincula identidad → rol en una ruta, opcionalmente con propagación.
• Ruta: el árbol de recursos: /, /dc, /nodes/pve01, /vms/101, /storage/nvme-ssd, /pool/Dev, etc.
• Privilegios efectivos: Proxmox calcula lo que puedes hacer en el momento del acceso, en función de todas las ACL coincidentes.

“Permiso denegado en Datacenter” suele significar: el usuario puede autenticarse, pero carece de uno o más privilegios requeridos para renderizar u operar algo en el ámbito /dc (o la GUI intentó obtenerlo en ese ámbito).

Dos verdades operativas:

1. La mayoría de las páginas de la GUI obtienen múltiples endpoints. Puede que tengas permiso para ver una VM, pero la barra lateral necesita recursos del clúster, estado de almacenamiento o métricas del nodo. Una llamada denegada puede romper toda la vista.
2. La ruta es el contrato. Si la ACL está en /nodes/pve01 pero estás mirando algo bajo /dc (Datacenter), no esperes milagros.

Broma #1: Dar a todos Administrator en / es como resolver colas de tickets desenchufando el teléfono del helpdesk. El silencio es real, pero también el desastre.

Datos interesantes y contexto histórico (las partes que importan)

Estos no son datos para una noche de trivial. Explican por qué los permisos de Proxmox se ven como se ven y por qué ciertos modos de fallo se repiten.

1. El sistema de permisos de Proxmox está fuertemente influenciado por la mentalidad Unix: identidades y grupos mapeados a un árbol de recursos. Por eso las rutas parecen “tipo sistema de archivos”.
2. Los roles por defecto codifican la intención operativa: PVEVMAdmin no es “administrador”, es “administrador de VMs”, y deliberadamente no concede todo a nivel Datacenter.
3. La configuración del clúster es distribuida: en un clúster, los datos de permisos se comparten vía el sistema de archivos del clúster. Un nodo particionado puede mostrar ACLs obsoletas y confundir el diagnóstico.
4. Históricamente, las UIs en productos de infra suelen sobreconsultar: las primeras consolas de administrador «single page app» consultaban endpoints amplios para poblar paneles. El comportamiento de la GUI de Proxmox hereda parte de ese patrón.
5. Los permisos finos de almacenamiento son una expectativa relativamente moderna: pilas de virtualización antiguas asumían “admins de almacenamiento = admins del hipervisor”. En Proxmox, los objetos de almacenamiento tienen rutas ACL explícitas, lo cual es bueno—hasta que las olvidas.
6. Los tokens de API son respuesta a la realidad de la automatización: contraseñas de larga duración en scripts son deuda operativa. Los tokens son mejores, pero solo si los limitas correctamente.
7. El principio de menor privilegio se popularizó por incidentes, no por elegancia: la proliferación de privilegios no es estética; es multiplicador de incidentes.
8. El RBAC de Proxmox está diseñado para equipos mixtos: administradores de virtualización, personal de almacenamiento, auditores y equipos de aplicaciones pueden coexistir—si dejas de convertir todo en “Administrator”.
9. La propagación es un clásico arma de doble filo: los permisos heredados son convenientes, pero también cómo un “acceso temporal” se vuelve “acceso para siempre”.

Cómo Proxmox evalúa roles y ACL (y por qué tu GUI miente por omisión)

Los roles son conjuntos de privilegios

Un rol es una lista nombrada de privilegios. Los privilegios son unidades atómicas como VM.Audit, VM.PowerMgmt, Datastore.Allocate, Sys.Audit, y así sucesivamente.

Punto clave: no otorgas un privilegio directamente a un usuario. Otorgas un rol mediante una ACL. El rol es el “paquete”, la ACL es el “dónde” y el usuario/grupo/token es el “quién”.

Las rutas de las ACL son un árbol de recursos, no una sugerencia

Pensa en ámbitos explícitos:

• /: todo, la raíz de todas las rutas.
• /dc: objetos a nivel datacenter (clúster, permisos, pools, inventario de almacenamiento, etc.).
• /nodes/<node>: objetos específicos de nodo (tareas, servicios, syslog, almacenamiento local en ese nodo).
• /vms/<vmid>: objetos específicos de VM/CT.
• /storage/<storageid>: permisos de objetos de almacenamiento.
• /pool/<poolname>: control de acceso por pool, útil para delegar grupos de VMs.

El “permiso denegado” en la vista Datacenter ocurre a menudo cuando otorgaste permisos de VM en /vms/101 pero no la capacidad de ver ciertos objetos del datacenter que la GUI consulta. Obtienes acceso parcial que parece acceso roto.

La propagación controla la herencia hacia abajo en el árbol

Una ACL puede propagarse (aplicarse a subrutas) o no. La propagación es poderosa. También es la forma en que accidentalmente concedes acceso a todas las VMs cuando querías “solo ese pool”.

Consejo operativo: propaga solo cuando la ruta ya es estrecha (como /pool/Dev), o cuando es realmente intencional (como /vms para operadores de VM). Evita la propagación en / a menos que estés creando conscientemente un superusuario.

Múltiples ACLs se combinan

Los usuarios pueden ser miembros de grupos, y los grupos pueden tener ACLs. Un usuario también puede tener ACLs directas. Proxmox calcula la unión de privilegios a través de todas las ACL coincidentes.

Por eso “eliminar al usuario del grupo admin” a veces no funciona: todavía tienen una ACL directa en algún lugar que olvidaste que existía.

La GUI es un cliente, no un oráculo de la verdad

La interfaz de Proxmox es excelente, pero sigue siendo un cliente web que llama a la API. Cuando algo se niega, puede mostrar solo un mensaje genérico. Tu trabajo es encontrar qué llamada a la API fue denegada y qué privilegio faltó.

En caso de duda, trata la GUI como un generador de síntomas y usa la CLI para inspeccionar ACLs y roles.

Cita (idea parafraseada): Gene Kranz enfatizaba que la fiabilidad viene de la disciplina y límites claros de responsabilidad, no de heroicidades.

Guía rápida de diagnóstico

Esta es la secuencia “no lo compliques”. Hazla en orden. Usualmente te dirá la pieza faltante exacta.

Primero: confirma identidad y realm

• ¿El usuario inicia sesión como user@pve vs user@pam vs user@ldap?
• ¿Otorgaste ACLs a la identidad del realm equivocada (común con AD/LDAP donde los nombres de usuario se solapan)?

Segundo: lista las ACLs que aplican

• Revisa las ACLs directas del usuario.
• Revisa la pertenencia a grupos y las ACLs de los grupos.
• Revisa si la propagación está activada y si la ruta de la ACL coincide con el área que falla.

Tercero: inspecciona la definición del rol

• ¿El rol realmente incluye el privilegio que crees que incluye?
• ¿Alguien “optimizó” un rol quitando privilegios “innecesarios” y rompió la GUI?

Cuarto: reproduce vía API e identifica el endpoint denegado

• Intenta la misma acción con pvesh como usuario privilegiado y compara.
• Mira los registros de tareas y mensajes de permiso denegado con contexto.

Quinto: comprueba la consistencia del clúster si el comportamiento difiere por nodo

• Si un nodo permite el acceso y otro lo niega, puede haber problemas con el sistema de archivos del clúster o un nodo parcialmente unido.

Sexto: solo entonces cambia ACLs

No hagas cambios a lo loco. Haz un cambio, prueba, revierte si es necesario. Los cambios de permisos son cambios en producción.

Tareas prácticas: comandos, salidas, decisiones (12+)

Todas las tareas asumen que estás ejecutando en un nodo Proxmox como root o un usuario admin. Los comandos son reales. Las salidas son representativas. Las decisiones son qué hacer a continuación.

Task 1: Confirmar la identidad del usuario (el realm importa)

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

Qué significa la salida: Hay dos usuarios “alice” en realms diferentes. Las ACLs se adjuntan al ID completo incluyendo el realm.

Decisión: Verifica cuál está iniciando sesión. Si la que se queja es de AD, debes otorgar a alice@ldap, no a alice@pve.

Task 2: Listar membresías de grupos (privilegios ocultos viven aquí)

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

Qué significa: Alice hereda ACLs de DevOps y VM-Operators.

Decisión: Audita esas ACLs de grupo antes de cambiar nada. La solución más rápida muchas veces es una ACL faltante en un grupo, no agregar ACLs puntuales al usuario.

Task 3: Volcar ACLs y buscar al usuario o grupo

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

Qué significa: Los operadores de VM tienen derechos de administrador de VM en el pool Dev. DevOps tiene auditoría en ámbito datacenter.

Decisión: Si Alice no puede abrir Datacenter porque la GUI necesita algo más que PVEAuditor, o amplías el rol auditor (con cuidado) o agregas una ACL estrecha para el privilegio faltante.

Task 4: Verificar contenido del rol (no supongas)

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                  │
└──────────────┴──────────────────────────────────────────────┘

Qué significa: El rol es mayormente de solo lectura, pero nota que incluye Permissions.Modify en este ejemplo (algunos entornos personalizan esto; los valores por defecto pueden variar).

Decisión: Si tu auditor puede modificar permisos, has creado una vía silenciosa de escalada de privilegios. Ajusta la definición del rol para que coincida con la intención.

Task 5: Enumerar todos los privilegios y detectar lo que falta

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

Qué significa: Los roles son paquetes; Administrator es comodín.

Decisión: Si te tienta usar Administrator, detente. Identifica el rol mínimo necesario y aplícalo en la ruta correcta.

Task 6: Comprobar si el usuario puede listar recursos del datacenter vía API (como 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"
  },
  ...

Qué significa: Como admin puedes recuperar información de usuarios. Esto confirma que el endpoint de la API existe y funciona.

Decisión: Si el usuario no puede cargar Datacenter, determina qué endpoint le está denegando. Usa herramientas de desarrollo del navegador o replica llamadas probables (tareas siguientes).

Task 7: Prueba rápida si el problema es “no puede ver nodos”

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
  }
]

Qué significa: Los nodos existen y son accesibles para un admin. Un usuario no admin podría recibir denegación si carece de Sys.Audit o privilegios equivalentes en /nodes o /.

Decisión: Si la barra lateral de Datacenter falla, asegúrate de que el usuario tenga al menos derechos de auditoría sobre /nodes o /dc según lo que quieras que vea.

Task 8: Inspeccionar inventario de almacenamiento; ACLs faltantes de almacenamiento provocan denegaciones sorpresivas

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"
  }
]

Qué significa: Existen objetos de almacenamiento; los paneles de la GUI consultan con frecuencia estos datos.

Decisión: Si un usuario puede gestionar VMs pero no adjuntar discos o explorar ISOs/copias de seguridad, agrega ACLs en /storage/<id> con un rol que incluya los privilegios de datastore necesarios.

Task 9: Mostrar ACLs actuales de forma legible (volcado completo)

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

Qué significa: Los permisos son escasos y claros. Buena señal.

Decisión: Si el usuario se queja de denegación en Datacenter, comprueba si /dc incluye suficientes privilegios de lectura para las secciones de la UI que necesita.

Task 10: Añadir una ACL de ámbito estrecho (ejemplo: permitir solo monitorización)

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

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

Qué significa: Los operadores de VM pueden auditar el estado de los nodos sin ser administradores de nodo.

Decisión: Si esto arregla la visibilidad en Datacenter, déjalo. Si expone más de lo deseado, llévalo a /nodes/pve01 o en su lugar concede solo derechos de auditoría en /dc más endpoints específicos (más difícil de gestionar).

Task 11: Validar uso de pools; las ACLs por pool son el mecanismo de delegación más limpio

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

Qué significa: Existen pools.

Decisión: Pon las VMs/CTs de equipos en pools y asigna roles en /pool/<pool> con propagación. Esto vence a las ACLs por VM para mantener la cordura.

Task 12: Confirmar que una VM está en el pool esperado (o no)

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"
}

Qué significa: La VM 101 está en el pool Dev, por lo que aplican las ACLs de /pool/Dev.

Decisión: Si un usuario no puede gestionar “su” VM, primero comprueba si la VM está en el pool correcto antes de editar ACLs.

Task 13: Detectar deriva de roles (los roles personalizados son donde las buenas intenciones mueren)

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

Qué significa: El rol personalizado carece de VM.Config.Disk y Datastore.AllocateSpace, por lo que las operaciones de disco pueden fallar.

Decisión: Decide si los operadores de VM deben gestionar discos. Si sí, actualiza el rol; si no, documenta esa limitación y proporciona una vía de petición para cambios de almacenamiento.

Task 14: Auditar tokens de API (a menudo sobreviven a las personas que los crearon)

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

Qué significa: Existen tokens y usan separación de privilegios (privsep=1), lo cual es bueno. Significa que los permisos del token son independientes de los del usuario.

Decisión: Asegúrate de que cada token tenga ACLs explícitas en las rutas mínimas que necesita. No dependas de permisos amplios del usuario.

Task 15: Comprobar salud del clúster cuando los permisos son inconsistentes entre nodos

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

Qué significa: El clúster tiene quórum; la configuración (incluidos permisos) debería ser consistente.

Decisión: Si tienes quórum y aún ves comportamientos desajustados, sospecha del caché del navegador, diferentes rutas de autenticación del realm, o problemas locales del nodo como desajuste de hora que afectan tokens.

Diseño de roles: qué crear, qué prohibir y qué mantener aburrido

El diseño RBAC es donde los entornos Proxmox se vuelven limpios o embrujados. La meta no es la perfección. La meta es: permisos predecibles que puedas explicar a las 03:00.

Principio 1: Prefiere ACLs de grupo sobre ACLs de usuario

Las ACLs de usuario escalan como un rumor: rápido, desordenado y difícil de retirar. Usa grupos para humanos. Usa tokens para automatización. Usa ACLs directas de usuario solo para acceso de emergencia o temporal con fecha de expiración que realmente cumplas.

Principio 2: Usa pools para delegación

Si no usas pools, haces ACLs de la forma difícil. Los pools te dan un identificador estable de “este equipo posee estas VMs/CTs”. Concede roles en /pool/TeamX con propagación. Mueve cargas entre pools cuando cambie la propiedad. Esa es la costura limpia.

Principio 3: Separa “puede operar VMs” de “puede mutar la infraestructura”

Los operadores de VM deberían poder:

• Iniciar/detener/reiniciar
• Acceso a consola
• Ver configuración y métricas
• Snapshot (tal vez)

Normalmente no deberían poder:

• Añadir nuevos backends de almacenamiento
• Editar la red del clúster
• Modificar permisos
• Gestionar nodos/servicios

Esto suena obvio hasta que te das cuenta de la frecuencia con la que la gente concede privilegios a nivel de nodo solo para detener un error de la UI.

Principio 4: Crea un pequeño número de roles personalizados y trátalos como código

Los roles por defecto existen por una razón. Los roles personalizados están bien, pero cada rol personalizado debe tener:

• una frase de propósito (“Operador de VM con derechos de adjuntar disco en Dev solo”)
• un camino de ámbito claramente definido donde está permitido
• un propietario (equipo) responsable de revisarlo trimestralmente

Principio 5: No “arregles” permiso denegado ampliando el ámbito

Si el usuario recibe denegación en Datacenter, la solución rara vez es “Administrator en /dc.” Normalmente es una de:

• identidad de realm equivocada
• ACL en la ruta equivocada
• rol faltante de un privilegio requerido por la UI
• membresía de pool equivocada
• ACL de almacenamiento faltante

Broma #2: La forma más rápida de resolver un ticket RBAC es eliminar RBAC. Los equipos de seguridad llaman a esto “desarrollo de carrera”.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición equivocada

Tenían un clúster Proxmox ordenado para servicios internos: runners de CI, caches de build, algunos entornos de apps “temporales” que se volvieron permanentes porque a nadie le gusta rehacer trabajo. Un ingeniero de plataforma creó un grupo “VM Admin” y aplicó PVEVMAdmin en /vms, asumiendo que sería suficiente para operaciones diarias.

Luego un desarrollador abrió un ticket: “La vista Datacenter está rota, permisos denegados.” El ingeniero abrió la GUI como el desarrollador y vio el banner de error. La suposición inmediata fue que el rol era erróneo, así que escalaron: añadieron PVEAdmin en /dc al grupo. Error desapareció. Ticket cerrado. Todos felices.

Una semana después, las copias de seguridad comenzaron a fallar—no porque no pudieran ejecutarse, sino porque alguien “útilmente” editó la configuración del almacenamiento de backups mientras depuraba otro problema. Tenían acceso porque PVEAdmin en /dc incluye amplios privilegios de datacenter. La configuración resultante era lo bastante válida para guardar, lo bastante errada para romper restauraciones. La falla solo salió a la luz durante una prueba de recuperación.

La causa raíz no fue malicia. Fue la suposición equivocada: que la vista Datacenter requiere privilegios de admin del datacenter. En realidad necesitaba visibilidad de auditoría hacia nodos y almacenamiento para los paneles de la GUI que cargaban. La solución correcta habría sido estrecha: otorgar PVEAuditor en /nodes y un rol de usuario de datastore en rutas de almacenamiento específicas, o afinar un rol personalizado con solo los privilegios de auditoría necesarios.

La remediación fue aburrida: eliminar la ACL amplia, añadir ACLs precisas y documentar “los errores de la GUI son errores de endpoints de la API, no fallas de rol”. Redujo su radio de impacto de inmediato.

Micro-historia 2: La optimización que salió mal

Un equipo de una empresa grande decidió que tenían “demasiados roles”. Intentaban estandarizar acceso entre virtualización, Kubernetes y bare metal. Alguien propuso una simplificación: crear un único rol personalizado de Proxmox llamado OpsStandard que cubriera el 95% de las necesidades. Sustrajeron privilegios de varios roles existentes y eliminaron todo lo que “parecía arriesgado”.

Al principio funcionó. Menos nombres de roles, menos líneas de ACL. Luego comenzó la rareza: migraciones de VM fallando para algunos usuarios, operaciones de snapshot denegadas intermitentemente y la UI a veces mostrando listas de almacenamiento vacías. Cada síntoma aparecía en una esquina diferente del producto, lo que hacía parecer un bug de Proxmox.

El problema real fue la “optimización”. Quitaron un puñado de privilegios que parecían tangenciales, pero de los que la GUI y los flujos de trabajo dependían. El rol todavía permitía encender VMs, así que la gente asumía que estaba bien. No lo estaba. Los privilegios denegados eran necesarios para consultas auxiliares y actualizaciones de estado.

Terminaron deshaciendo la simplificación. Volvieron a un pequeño conjunto de roles alineados a responsabilidades y limitaron el ámbito usando pools y rutas de almacenamiento en lugar de “un rol para gobernarlos a todos”. El diseño final tenía más líneas en las ACLs, pero menos incidentes.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo cercano a finanzas ejecutaba Proxmox para cargas sujetas a cumplimiento. Tenían una costumbre que todos se burlaban: revisiones trimestrales de acceso. No era un ejercicio en una hoja de cálculo—era una revisión real de grupos, roles y rutas ACL, con una segunda persona verificando.

Durante una revisión notaron algo sutil: una cuenta de contratista antigua estaba deshabilitada, pero su token de API seguía existiendo. El token tenía sus propias ACLs porque la separación de privilegios estaba habilitada. Además tenía acceso a /storage/backup-nfs con un rol que permitía leer backups.

No había pasado nada malo todavía. Ese es el punto. Revocaron el token, quitaron la ACL y rotaron algunos secretos. Más adelante ese año, otro sistema fue comprometido y los atacantes sondaron APIs internas. El token de Proxmox habría sido una vía fácil para robar backups si aún existiera.

Lo que los salvó no fue una herramienta ingeniosa. Fue la práctica aburrida: tratar los tokens como credenciales de producción, revisarlos y borrarlos cuando el servicio o la persona desaparecen.

También mantuvieron su diseño RBAC dolorosamente simple: pools para propiedad, grupos separados para auditoría vs operación, y sin roles personalizados salvo que exista un requisito por escrito. Como resultado, cuando veían “permiso denegado”, el diagnóstico era rápido porque el sistema era legible.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “Permiso denegado” al hacer clic en Datacenter, pero la consola de VM funciona

Causa raíz: El usuario tiene privilegios a nivel VM (/vms/<id> o /pool/<pool>) pero carece de derechos de auditoría para nodos/almacenamiento que la UI del Datacenter consulta.

Solución: Añade un rol de auditoría en /nodes (o /dc si procede) y un rol de auditoría/usuario de datastore en el /storage/<id> requerido. Manténlo de solo lectura a menos que quieras más.

2) Síntoma: Funciona para alice@pve pero no para alice@ldap

Causa raíz: ACLs otorgadas a la identidad del realm equivocada.

Solución: Otorga ACLs a la identidad correcta (user@realm). Considera deshabilitar cuentas locales duplicadas para reducir la confusión.

3) Síntoma: El usuario puede iniciar/detener VMs pero no puede adjuntar ISOs

Causa raíz: Privilegios de datastore faltantes en la ruta de almacenamiento de ISOs (/storage/<id>), no es un problema de privilegios de VM.

Solución: Añade un rol de usuario/auditor de datastore en ese almacenamiento, o mueve las ISOs a un almacenamiento con ACLs apropiadas.

4) Síntoma: El trabajo de backup falla con errores de permisos solo cuando lo ejecuta la automatización

Causa raíz: El token de API tiene separación de privilegios habilitada y no hereda las ACLs del usuario; el token carece de sus propias ACLs.

Solución: Añade ACLs para la identidad del token en las rutas requeridas, o deshabilita la separación de privilegios solo si aceptas el acoplamiento (normalmente no lo harás).

5) Síntoma: La página Datacenter → Permisos es inaccesible para “auditores”

Causa raíz: El rol auditor carece de privilegios de auditoría relevantes para objetos de permisos, o intencionalmente lo restringiste y la GUI está denegando correctamente.

Solución: Decide la intención. Si deben ver permisos, añade el privilegio de auditoría necesario mediante la actualización del rol. Si no, deja de prometer acceso a esa página.

6) Síntoma: El usuario ve algunas VMs pero no otras en el mismo equipo

Causa raíz: Las VMs no están asignadas consistentemente al pool, o las ACLs por VM divergieron con el tiempo.

Solución: Normaliza usando pools. Mueve VMs al pool correcto; elimina ACLs por VM salvo que haya una excepción documentada.

7) Síntoma: Los permisos parecen correctos, pero el usuario sigue recibiendo denegación tras cambios

Causa raíz: Caché de sesión/token del navegador; el usuario está conectado en otro realm; o cambiaste membresía de grupo pero la sesión no se ha refrescado.

Solución: Pide al usuario cerrar sesión/abrir sesión; confirma el realm en la etiqueta superior derecha; vuelve a comprobar con la CLI y asegúrate de haber modificado la identidad correcta.

8) Síntoma: Diferentes nodos se comportan distinto para el mismo usuario

Causa raíz: Inconsistencia de clúster (problemas de quórum, nodo no completamente unido) o diferencias en la integración de autenticación local por nodo.

Solución: Comprueba pvecm status, asegura quórum; verifica la configuración del realm en todos los nodos; arregla la salud del sistema de archivos del clúster antes de tocar ACLs.

Listas de verificación / plan paso a paso

Checklist A: Construir RBAC correctamente para un equipo (usuarios humanos)

1. Crea (o usa) un realm de autenticación que coincida con la identidad corporativa (LDAP/AD/OIDC). No crees usuarios locales duplicados salvo que lo necesites.
2. Crea grupos que mapeen responsabilidades, no organigramas: VM-Operators, VM-Auditors, Storage-Operators.
3. Crea pools por equipo o entorno: Dev, Prod, Analytics.
4. Coloca VMs/CTs en pools como fuente de verdad para la propiedad.
5. Concede roles en /pool/<pool> con propagación:
   • PVEVMUser o PVEVMAdmin dependiendo de si pueden cambiar la configuración.
6. Concede PVEAuditor en /nodes si necesitan ver el estado de nodos en la GUI.
7. Concede roles de datastore en rutas específicas /storage/<id> para acceso a ISO/backup si es necesario.
8. Documenta lo que no pueden hacer (¿snapshots? ¿redimensionar discos? ¿migraciones?). Menos sorpresas = menos solicitudes de “hazlos admin”.

Checklist B: Arreglar un ticket en vivo “Permiso denegado en Datacenter” sin empeorarlo

1. Confirma el realm y el ID exacto del usuario (user@realm).
2. Lista los grupos del usuario y las ACLs existentes.
3. Identifica la página/acción que falla. Pide la ruta exacta de clics y la hora.
4. Comprueba si el usuario puede:
   • listar nodos (auditoría)
   • listar almacenamiento (auditoría)
   • ver el pool y sus miembros
5. Si falta, añade las ACLs mínimas de auditoría en la ruta correcta.
6. Vuelve a probar con el usuario. Si se arregla, para. No “mejorarlo” más en caliente.
7. Si no se arregla, identifica el endpoint denegado inspeccionando registros de tareas o reproduciendo con llamadas API.
8. Sólo como último recurso, concede temporalmente un rol más amplio con límite de tiempo y plan de reversión.

Checklist C: Automatización basada en tokens hecha de forma segura

1. Crea un usuario de servicio dedicado por dominio de automatización (por ejemplo, svc-terraform@pve).
2. Crea tokens por entorno (tf-dev, tf-prod) para poder revocar quirúrgicamente.
3. Mantén privsep=1 y asigna ACLs explícitas a cada token. No te aproveches de las ACLs del usuario.
4. Concede acceso en ámbito de pool y almacenamiento requerido, no en /.
5. Revisa tokens trimestralmente y elimina los que no se usan. Rota credenciales cuando cambien responsabilidades o pipelines.

Preguntas frecuentes (8+)

1) ¿Por qué Proxmox muestra “permiso denegado” en Datacenter cuando solo quiero acceso a VMs?

Porque la GUI carga datos a nivel datacenter y de nodos para rellenar la barra lateral, paneles y estados. Las ACLs solo para VM no cubren necesariamente esas llamadas a la API.

2) ¿Debería simplemente otorgar PVEAuditor en / para que todos vean todo?

No. Otorga derechos de auditoría en /nodes y /dc solo si es necesario, y considera qué significa “ver todo” en tu organización. La visibilidad también es acceso.

3) ¿Cuál es la forma más segura de dar a un equipo acceso a “sus” VMs?

Usa pools. Pon sus VMs/CTs en /pool/Team y asigna un rol enfocado en VMs allí con propagación. Es limpio y reversible.

4) ¿Por qué mi operador de VM no puede adjuntar discos o montar ISOs?

Las operaciones de disco/ISO suelen tocar objetos de almacenamiento. Necesitas privilegios apropiados en /storage/<id> además de los privilegios de VM.

5) ¿Los tokens de API heredan los permisos del usuario?

No si la separación de privilegios está habilitada para el token (privsep=1). En ese caso, los tokens necesitan sus propias ACLs. Normalmente es lo que quieres para automatización.

6) He otorgado el rol correcto, pero sigue diciendo denegado. ¿Qué hago ahora?

Confirma que lo otorgaste a la identidad correcta (user@realm), en la ruta correcta, con propagación si es necesario. Luego pide al usuario cerrar sesión/abrir sesión para refrescar la sesión.

7) ¿Está bien personalizar los roles por defecto?

Puedes hacerlo, pero trátalo como modificar una biblioteca de producción: versiona mentalmente, documenta y espera sorpresas. Prefiere crear un rol personalizado nuevo para que los valores por defecto sigan previsibles.

8) ¿Cómo evito la proliferación de privilegios con el tiempo?

Usa ACLs basadas en grupos, alcance por pools y revisiones trimestrales de ACLs y tokens. Elimina ACLs puntuales de usuarios salvo que haya una excepción por escrito.

9) ¿Por qué funciona en un nodo y no en otro?

O bien no estás en un estado de clúster consistente (distribución de configuración/quórum), o la configuración del realm difiere por nodo, o el usuario se autentica de forma distinta. Arregla la consistencia primero.

10) ¿Cuál es el lugar “correcto” para asignar permisos: /dc o /?

Casi nunca /. Usa /dc para necesidades de lectura a nivel datacenter (y solo para roles admin de confianza para escritura). Usa pools, nodos y rutas de almacenamiento para todo lo demás.

Conclusión: próximos pasos que puedes hacer hoy

Los errores “permiso denegado” en Datacenter de Proxmox no son aleatorios. El sistema te está diciendo que tu historia RBAC no coincide con la forma en que la GUI y la API acceden realmente a los recursos.

Haz estos siguientes pasos:

1. Elige un usuario problemático y mapea su identidad → grupos → rutas ACL → roles. Escríbelo en cuatro líneas. Si no puedes, tu RBAC ya es demasiado ingenioso.
2. Mueve las cargas de equipo a pools y deja de hacer ACLs por VM como juego de Whac-A-Mole.
3. Añade acceso mínimo de auditoría para nodos/almacenamiento solo cuando sea necesario para visibilidad. No uses “acceso Datacenter” como excusa para admin de datacenter.
4. Inventaría tokens de API, confirma privsep=1 y asegúrate de que cada token tenga ACLs explícitas y estrechas.
5. Programa una revisión trimestral de RBAC. Sí, es aburrido. Por eso funciona.