Modelo de acceso de vStack Center

Problema y propósito

Un mismo clúster atiende a muchos usuarios: el administrador de la plataforma, el administrador de un VDC (centro de datos virtual) concreto, un usuario que trabaja solo con sus propias máquinas y un observador que solo necesita acceso de lectura e informes. Todos ellos usan el mismo endpoint HTTPS del clúster y llaman a los mismos métodos. Un único indicador de «administrador / no administrador» no permite distinguirlos: «ver una red» y «editar su propia red» son permisos distintos, y el segundo además se aplica a un conjunto limitado de objetos.

Esto exige un modelo de tres capas en lugar de una simple lista de roles. Un rol está formado por privilegios, un privilegio enumera los métodos a los que concede acceso, y un atributo de ámbito limita el privilegio a objetos concretos. Sin una comprensión clara de estas tres capas, el comportamiento de la plataforma puede parecer incoherente: a un usuario con rol de administrador en un VDC se le deniega el acceso en otro, y un método disponible para «todos los usuarios autorizados» devuelve conjuntos de campos distintos según el rol.

Esta página explica el modelo. Para la creación y el mantenimiento de cuentas, consulte Cómo administrar usuarios; para crear y asignar un rol personalizado, consulte Cómo configurar roles y privilegios; para las sesiones y la política de inicio de sesión, consulte Cómo configurar el inicio de sesión y administrar sesiones.

Modelo y entidades

El acceso en vStack Center se basa en cuatro entidades.

Usuario. Una cuenta del clúster con un id numérico, un nombre name, un nombre completo fullname y las marcas de tiempo created y modified. Al crearse, la cuenta no tiene contraseña; la contraseña se establece en una llamada aparte. Los contadores de inicio de sesión se almacenan junto al perfil: failed_login_attempts, first_failed_at y locked_until. Los identificadores id < 10 están reservados para las cuentas integradas: la plataforma prohíbe eliminarlas o modificar sus asignaciones de roles.

Privilegio. Una unidad de permiso. Un privilegio tiene un id, un nombre legible name, una categoría category_id, un conjunto de scope_ids y su campo principal, methods: una lista de nombres de métodos JSON-RPC a los que el privilegio concede acceso. Es el privilegio, y no el número de rol, lo que determina quién puede llamar a un método.

Atributo de ámbito. Un atributo que limita un permiso a un subconjunto de objetos. Tiene un id, un name y un indicador self_referencing. Existen dos tipos de atributos, con una diferencia fundamental entre ellos:

Atributo	self_referencing	Origen del valor	Qué limita
vdc_id	false	la tabla de asignaciones user_role_scope	la lista de VDC en los que se aplica el rol
creator	true	se genera a partir del user_id del llamante	los objetos creados por el llamante

Rol. Un conjunto con nombre de privilegios más un conjunto de atributos de ámbito. Los roles se clasifican en fijos o personalizados según su rango de identificadores.

ID	Nombre del rol	Tipo	Nivel
1	Cluster Master	fijo	clúster
2	vDC Admin	fijo	VDC
3	vDC User	fijo	VDC
4	vDC Viewer	fijo	VDC
5	Resource Viewer	fijo	clúster
6	Security Admin	fijo	clúster
7	VM Developer	fijo	VDC
≥ 10000	nombre personalizado, de hasta 64 caracteres	personalizado	lo determinan los atributos de ámbito

Los roles Security Admin y VM Developer se introdujeron en la versión 3.0.3. El primero opera a nivel de clúster y concede acceso al registro de seguridad y a la auditoría; el segundo opera dentro de un VDC y está pensado para crear y configurar máquinas virtuales.

Los roles fijos tienen el campo creator vacío (null) y no se pueden modificar ni eliminar. En un rol personalizado, creator almacena el id del usuario que lo creó. El rol Cluster master no está vinculado a ningún ámbito: su scope_ids es una matriz vacía, por lo que se aplica a todo el clúster.

La quinta entidad es una relación y no un objeto: una asignación. Un rol se asigna a un usuario junto con un valor de atributo de ámbito, dentro de un VDC concreto, y no sin ámbito. Un mismo usuario puede tener el rol vDC admin en un VDC y vDC viewer en otro.

Cómo funcionan las comprobaciones de acceso

Cada solicitud pasa por cuatro comprobaciones sucesivas.

1. Sesión. El clúster valida el token de sesión y lo sustituye por un identificador numérico de usuario; a partir de ese momento, el usuario se identifica dentro del clúster mediante este identificador. Una solicitud sin token se rechaza con el código -9494 ("No session token") antes de que se ejecute cualquier lógica del método.
2. Roles del llamante. A partir del identificador se construye un mapa de asignaciones: qué roles tiene el usuario en qué VDC. Los usuarios pueden ver su propio mapa; cada asignación incluye el VDC, el rol, el nombre del rol y un indicador de cuenta GI.
3. Privilegio. El método se compara con las listas methods de los privilegios que otorgan los roles del usuario. Si falta el privilegio, se deniega el acceso. El número de rol no importa aquí: un rol solo cuenta como conjunto de privilegios.
4. Ámbito. Si un privilegio tiene scope_ids, el permiso se aplica únicamente a los objetos de ese ámbito. Los valores de vdc_id proceden de las asignaciones de roles; los valores de creator proceden del uid del llamante. Un scope_ids vacío indica un privilegio global.

La diferencia entre un permiso global y uno con ámbito se ve en la propia asignación: cada par de rol y atributo de ámbito enumera valores del atributo o tiene un indicador «sin restricciones». Este indicador significa que las asignaciones no contienen valores y que el rol no está restringido por ese atributo. Por ejemplo, el rol vDC admin puede tener su atributo vdc_id restringido a dos VDC, mientras que el rol Resource viewer no tiene ningún atributo de ámbito.

Los privilegios se agrupan en categorías. Una categoría solo agrupa privilegios; no influye en las comprobaciones de permisos. El conjunto de categorías se carga inicialmente en la base de datos del clúster y crece a medida que la plataforma incorpora dominios. Las diez primeras son vDC, VM, Network, Edge, Storage, Node, Cluster, User, Misc y Auth; a ellas se han añadido Security, User Interface, Unified Storage, OS Image Library y Backup.

nota

El ejemplo de la documentación de la API enumera solo las diez primeras categorías, mientras que la base de datos contiene quince. La discrepancia está en el ejemplo, no en el comportamiento de la plataforma: se devuelve el catálogo completo de categorías, así que utilice el conjunto real de categorías de su clúster.

Dos ejemplos del registro de privilegios muestran ambos tipos de restricciones:

Privilegio	Categoría	Ámbito	Concede acceso al método
1000 View vDC	1 (vDC)	[1] — vdc_id	vdc-list
2010 Edit Own Network	3 (Network)	[2] — creator	net-set

El primero se aplica en los VDC donde está asignado el rol. El segundo se aplica únicamente a las redes creadas por el llamante, con independencia del VDC.

Límites del modelo

El modelo de privilegios no abarca la propia gestión de usuarios. Muchos métodos del grupo user-* requieren un rol global y devuelven a todos los demás el código -403 con el mensaje "Access denied". Esto se aplica a user-list, user-get, user-create, user-delete, user-unlock, user-role-assign, user-role-deassign, user-roles-map y a los métodos de restricción user-remote-* y user-vhost-*. Los permisos de administrador del clúster no se pueden conceder parcialmente; se trata de un conjunto de permisos cerrado de forma deliberada.

El mismo principio impone cuatro restricciones que impiden crear un rol personalizado que sea «casi Cluster master»:

Restricción	Motivo	Qué hacer en su lugar
Los privilegios de gestión de roles 7111–7113 no se pueden asignar a un rol personalizado	De lo contrario, el rol podría ampliar sus propios permisos	Deje la gestión de roles a Cluster master
Un atributo autorreferente (creator) está prohibido en los scope_ids de un rol personalizado	Su valor se genera a partir de user_id, por lo que no hay ningún valor que vincular al rol	Use vdc_id y, para la restricción «solo objetos propios», use los privilegios Own existentes
Los roles fijos (id < 10000) no se pueden modificar ni eliminar	Definen los contratos básicos de la plataforma	Cree un rol personalizado con el conjunto de privilegios necesario
Las cuentas con id < 10 no pueden cambiar sus asignaciones de roles ni eliminarse	Las cuentas integradas mantienen el clúster en funcionamiento	Cree un usuario aparte

Otro comportamiento que puede sorprender al principio: la misma operación puede devolver distintas cantidades de datos según el rol. Cualquier usuario autorizado puede leer la configuración de seguridad del clúster, pero, aunque todos pueden ver los requisitos de contraseña, solo Cluster master puede ver el límite de intentos fallidos y la duración del bloqueo.

Dónde encontrarlo en la interfaz

Las cuentas y los roles están en la misma sección. Ruta: Provider Data Center → Users & Roles. La sección tiene dos pestañas: Users, una tabla de cuentas con las columnas Name, Status, Full Name, Created y Changed; y Roles, una tabla de roles con las columnas Name, scope, Creator, Created y Modified. La columna scope de la tabla de roles es el conjunto de atributos de ámbito del rol.

Un rol se abre en una pantalla aparte (la barra de direcciones muestra #/panel/allusers/roles/). Allí los privilegios se agrupan en secciones: vDC, VM, Network, Edge, Storage, Node, Cluster, User, Misc, Auth, Security y User Interface. En la pantalla de un rol fijo, los botones Actions, Reset y Save changes están deshabilitados, lo que refleja la prohibición de modificar los roles fijos.

Véase también

• Creación de cuentas, contraseñas, desbloqueo y restricciones de red — Cómo administrar usuarios.
• Creación de un rol personalizado y asignación de un rol en un VDC — Cómo configurar roles y privilegios.
• Sesiones, política de contraseñas y bloqueo de cuentas — Cómo configurar el inicio de sesión y administrar sesiones.
• Conjuntos exactos de campos y lista completa de códigos de error — Campos y códigos de error de los métodos de acceso.

Métodos de la API

Operaciones de la API tratadas en esta página: privilege-categories, privilege-list, privilege-scopes, role-list, role-get, role-privilege-list, user-role, user-roles, user-roles-v2, user-roles-map, auth-security-settings-get — consulte la referencia de la API.