Jerarquía probada

1. Clientes
2. Clústeres
3. Nodos
4. VMs / CTs
5. Plantillas
6. Almacenamiento
7. Redes

Los permisos se heredan a lo largo de este árbol. En cada nivel se comprueba qué puede ver y qué puede modificar cada cuenta.

Cuatro dimensiones

• GUI

  Interfaz real

  La batería usa los controles reales — menús, pestañas, botones y menús contextuales — exactamente como lo haría cada usuario, y registra qué se muestra, se oculta o se desactiva.

• API

  Llamadas directas

  Las mismas operaciones se envían directamente a la API. Se usa cuando el producto no ofrece un control en la interfaz o los permisos de la cuenta lo ocultan; siempre se indica en el informe.

• Aislamiento

  Barridos de fugas

  Cada lectura — listados, paneles, búsquedas, mapas y topología — debe devolver solo los recursos de la propia cuenta. Cualquier cliente, clúster, nodo, VM o CT ajeno cuenta como fuga.

• Seguridad

  Pruebas de aislamiento de escritura

  Se intentan acciones de gestión — crear, editar, borrar, encender/apagar, migrar, clonar — fuera de los permisos de la cuenta y deben ser rechazadas. También se prueban el rate limiting de la API y el bloqueo de cuentas.

Cuentas probadas

15 cuentas cubren todos los ámbitos de permiso: global (superadministrador, administrador y solo lectura), cliente, clúster, nodo y VM/CT individual, cada una con rol de Administrador, Operador o Lector — además de una cuenta sin ningún permiso, que no debe ver ni hacer nada.

Cómo leer los resultados

• PASSLa cuenta se comportó exactamente como se esperaba: permitida donde tiene derecho, bloqueada donde no.
• FAILEl resultado no coincide con lo que exige el modelo de permisos.
• SKIPLa comprobación no aplica a esa cuenta o entorno, así que no cuenta ni como acierto ni como fallo.
• FUGASLa cuenta accedió a datos fuera de su asignación. El objetivo es siempre cero.
• BLOQUEOS CORRECTOSAcciones prohibidas que se denegaron exactamente como debían.