Manual

Cuentas y acceso

Una cuenta es una identidad de hv, distinta del acceso root a dom0 o del acceso al sistema operativo de una VM. Las cuentas y los grupos pertenecen a un Silo. Antes de conceder acceso, decida si hace falta trabajar en un Proyecto, en todos los del Silo o en la infraestructura de la flota. Mantenga una sesión administradora funcional durante las pruebas.

Conceder el rol adecuado

Use Acceso al proyecto para sus miembros, Acceso al silo para el ámbito completo del Silo y Sistema, Acceso a la flota para infraestructura. Un grupo contiene cuentas de su propio Silo. Revise el destinatario y el recurso antes de guardar una concesión.

Una concesión más amplia puede permitir una acción aunque la pertenencia al Proyecto sea más limitada. Los ámbitos de un token pueden restringirla aún más. Pruebe con la cuenta destinataria: la vista del administrador no demuestra qué puede hacer un miembro.

Dar acceso al equipo a production

Suponga que una persona necesita consultar web-01 y otra crear y operar VM en production. Confirme primero que sus cuentas pertenecen al mismo Silo que el Proyecto compartido. Abra Acceso al proyecto en production, seleccione las cuentas o el grupo previstos y conceda el rol de lector a quien solo consulta y el de colaborador a quien opera cargas. Reserve la administración del Proyecto para quien deba gestionar también miembros y el propio Proyecto.

Compruebe el Proyecto y el destinatario antes de guardar. Nombres de usuario parecidos en distintos contextos no son identidades intercambiables. Si el equipo ya dispone de un grupo en ese Silo, una concesión al grupo permite expresar la necesidad común sin repetir concesiones individuales. Revise sus miembros como parte de la decisión.

Pruebe cada resultado desde la sesión del miembro. El lector debe poder consultar el Proyecto sin recibir permisos de operación por esta concesión. El colaborador debe poder realizar el trabajo previsto dentro del Proyecto, pero eso no concede mantenimiento de Hosts ni migración en vivo. Si alguna cuenta puede hacer más de lo previsto, revise sus roles de Silo y flota además del rol del Proyecto: un rol más limitado no anula permisos más amplios.

Si web-01 no aparece, revise el Silo activo, la pertenencia al Proyecto y la propiedad antes de cambiar la visibilidad de la infraestructura. Si aparece pero se rechaza una operación, identifique su permiso. Conceder administración de flota ante cualquier rechazo daría al equipo más control del necesario. Proyectos explica las comprobaciones de visibilidad y cuotas, que son independientes de los roles.

Proteger el inicio de sesión

Abra Ajustes, Seguridad para registrar un autenticador TOTP. Confirme el código actual y conserve los códigos de recuperación mostrados una sola vez. Cada uno funciona una vez. La flota puede exigir segundo factor en Sistema, Ajustes, Seguridad, Exigir un segundo factor a los roles de flota. La política del Silo puede exigirlo a sus miembros. Ningún perfil de instalación lo exige por defecto.

Cuando el registro es obligatorio y no hay un segundo factor activo, un administrador de flota emite un código de registro mediante el procedimiento de cuentas. Restablecer el segundo factor de otra cuenta termina sus sesiones y revoca sus tokens de API. Tras activar una política obligatoria, pueden rechazarse tokens antiguos emitidos sin verificar el segundo factor; sustitúyalos desde una sesión que sí lo haya verificado.

Antes de exigir un segundo factor, registre a los administradores que gestionarán la recuperación y pruebe un inicio de sesión con el autenticador. Guarde los códigos de recuperación donde su titular pueda recuperarlos si pierde el dispositivo. Solo se muestran una vez; ese es el momento de conservarlos. Una captura en una conversación compartida de soporte no es un lugar adecuado.

Después de cambiar la política, pruebe la cuenta afectada y las automatizaciones que utilicen sus tokens. Si un token se rechaza por ser anterior a la verificación exigida, emita su sustituto desde una sesión debidamente verificada. Restablecer el segundo factor de otra cuenta interrumpe su acceso: cierra las sesiones existentes y revoca los tokens de API. Coordine el acceso de reemplazo con su titular; no cambia únicamente el autenticador.

Proveedores externos de identidad

hv admite el inicio de sesión con LDAP, OIDC y SAML. Se configuran para un Silo en la configuración del orquestador y no eluden roles ni ámbitos de tokens. LDAP necesita transporte protegido, base y filtro de búsqueda correctos e identificación estable. OIDC requiere el callback registrado exacto, un emisor de confianza y una política de admisión. SAML usa un certificado de firma fijado, identificadores IdP/SP y su callback propio, no el de OIDC.

La administración del proveedor debe preparar esos valores. Después se vincula al Silo previsto, se valida la configuración y se reinicia el servicio mediante el procedimiento del despliegue. Pruebe una cuenta permitida, otra denegada y la indisponibilidad del proveedor antes de depender de él. El aprovisionamiento automático debe usar el rol de Silo previsto; no debe suponerse que concede administración de flota. Conserve una identidad administradora operativa hasta completar esas comprobaciones.

Tokens de API y MCP

Cree tokens con ámbitos limitados en Ajustes, Tokens de acceso. Guarde el valor de forma privada; se muestra una sola vez. Una cuenta de automatización debe recibir solo los roles y ámbitos necesarios. Revoque los tokens que ya no se usen. Las sesiones de navegador y los tokens son distintos.

El servidor MCP también utiliza un token de cuenta y comprueba sus ámbitos y roles. Confirmar una modificación no concede permisos adicionales. Revise las tareas devueltas para comprobar que terminó.

Problemas habituales

Ante un 403, revise acción, destino del rol y ámbitos del token. Un 404 puede ocultar un objeto fuera de la visibilidad de la cuenta. Si falla repetidamente el inicio de sesión, compruebe reloj, confianza del proveedor y límites de intentos. No resuelva un permiso aislado concediendo administración global. Evite eliminar la última identidad de acceso o vía administrativa útil durante los cambios de proveedor.