Recientemente, me he estado pegando un poco con el tema de los permisos de Hyper-V, algo que no había hecho antes (era feliz, entrando como Administrador en mis Host Hyper-V de pruebas, sin más preocupaciones). Aprovecho para colgar aquí mis conclusiones, que espero sean acertadas.
Introducción a los Permisos en Hyper-V
En Hyper-V, por defecto sólo los miembros del grupo Administradores tienen permisos para Administrar Hyper-V, y no sólo esto, sino que tienen barra libre de permisos, mientras que el resto de usuarios, a Hyper-V, ni lo huelen. Además, la configuración de permisos en Hyper-V es local en cada Host,y no puede gestionarse desde la herramienta administrativa Hyper-V Manager.
Esta situación resulta algo paradójica, ya que lo típico al principio, es utilizar un usuario administrador para instalar y configurar Hyper-V, y hasta aquí ningún problema, todo genial. Sin embargo, cuando se quieren ajustar los permisos de Hyper-V, es como si nos hubiésemos encontrado con un agujero negro.
Entonces ¿Esto a qué se debe? ¿En qué se basan los permisos de seguridad en Hyper-V? ¿Existe alguna forma de poder configurar permisos en Hyper-V de una forma más restringida?
La asignación de permisos en Hyper-V se basa en Authorization Manager (AzMan), por lo que deberemos utilizar la consola administrativa de Authorization Manager (AzMan.msc, se trata de una consola MMC, de las de toda la vida) si deseamos personalizar los permisos en Hyper-V. Otro tema importante es que el Almacén de información de autorización (Authorization Store) utilizado por Hyper-V y Authorization Manager, se basa en un fichero XML local en cada Host. Por lo tanto, a priori, parece que si queremos personalizar los permisos de una granja de Hosts Hyper-V, tendremos que repetir la misma tarea en cada Host (be scripter, my friend ;-).
Este es el primer paso, comprender la problemática, y tomar una primera impresión de cómo resolverla y de su motivo (más o menos).
Introducción a los permisos con Virtual Machine Manager 2008 R2
Vista la problemática en Hyper-V, surge la duda de si con Virtual Machine Manager 2008 R2 mejoraría la cosa, y la verdad es que mejora, y mucho. Pero además de mejorar, es importante tener claro, que la cosa cambia. Me explico:
- Sin Virtual Machine Manager, utilizaremos la herramienta administrativa Hyper-V Manager, de tal modo que al conectarnos a un Host Hyper-V con dicha herramienta, nos permisos de acceso que tendremos quedarán regidos por Authorization Manager (AzMan) y su correspondiente fichero XML de configuración, como ya hemos avanzado, y como veremos en más profundidad a lo largo y ancho del presente artículo.
- Con Virtual Machine Manager, utilizaremos la herramienta administrativa VMM Administrator Console o en su defecto el VMM Self-Service Portal, pero en ningún caso utilizaremos el Hyper-V Manager. Esto implica una diferencia fundamental. El tema es que el VMM Agent que corre en cada Host, se ejecuta bajo la identidad de Local System, por lo tanto dispone de barra libre de permisos en Hyper-V. En este caso es el VMM Server quien gestiona la seguridad, almacenando la correspondiente configuración de permisos en la base de datos de configuración de VMM (en SQL Server). Es decir, un usuario a través de la VMM Administrator Console o del VMM Self-Service Portal, se comunica con el VMM Server, que se comunica con el VMM Agent correspondiente, que pasa por AzMan para acceder a Hyper-V, siendo el VMM Server quién regula qué y quién puede hacer qué cosa (la filosofía de la cebolla: por capas).
Realmente, con Virtual Machine Manager 2008, nos olvidamos de AzMan, ya que el VMM Agent va sobradito de permisos. Esto permite y facilita poder almacenar la configuración de seguridad en la base de datos de VMM, una capa adicional que nos ayudará entre otras cosas, a tener un repositorio común compartido (recordemos que con AzMan la configuración es local en cada Host).
Virtual Machine Manager 2008 almacena su propia información y configuración de Roles en SQL Server, como ya hemos avanzado. Así, por ejemplo, con la propia instalación de Virtual Machine Manager 2008 R2, se incluye un Role Administrator, que tiene Control Total sobre toda la infraestructura de Virtualización, y sobre el cual, podremos modificar su pertenencia. Adicionalmente, podemos crear nuevos Roles, pudiendo diferenciar entre dos tipos de Roles:
- Delegated Administrator. Orientado a Delegar la Administración de los Host y Librerías. Este tipo de usuarios accederá a través de la VMM Administrator Console, y podrán realizar todas las funciones (Control Total) sobre los Grupos de Host (Host Groups) y Librerías (Server Libraries) que le asignemos. Imaginemos una empresa muy grande, muy grande, en la que se crea un Host Group para cada región geográfica (ej: para cada país), y se crea un Role de tipo Delegated Administrator para cada uno de estos Host Groups, asignando como miembros a los usuarios correspondientes.
- Self-Service User. Orientado a Delegar la Administración a nivel de Máquina Virtual. Este tipo de usuario accederá a través del VMM Self-Service Portal o de Windows PowerShell VMM command Shell, y sólo podrá realizar las acciones que le indiquemos (Start, Stop, Pause and Resume, Checkpoint, Remove, Local Administrator, Remote connection, Shutdown) sobre las Máquinas Virtuales de su propiedad. Además, también es posible especificar qué Plantillas de Máquina Virtual pueden utilizar los usuarios para crear nuevas Máquinas Virtuales (o bien, que no puedan utilizar ninguna Plantilla, y en consecuencia, que no puedan crear nuevas Máquinas Virtuales), así como indicar que Librerías pueden utilizar para almacenar Máquinas Virtuales. Evidentemente, la utilización de este tipo de Roles, hace necesario instalar el VMM Self-Service Portal, un componente opcional de Virtual Machine Manager 2008. También es interesante planificar la creación y/o utilización de Grupos de Directorio Activo, es decir, podemos crear un Role y como miembro incluir un Grupo de Directorio Activo, adicionalmente establecer como propietario de ciertas Máquinas Virtuales a dicho Grupo de Directorio Activo, y con esto, todos los miembros de dicho Grupo podrán administrar dichas Máquinas Virtuales (una buena planificación de grupos, roles y permisos, es un factor de éxito en una implantación de Virtual Machine Manager y VMM Self-Service Portal). Ahora llega el ejemplo. Imaginemos una empresa muy grande, muy grande, con un departamento de consultoría y desarrollo de proyectos. Podemos crear un Host Group con uno o varios Hosts para que lo usen, y del mismo modo, crear un Role de tipo Self-Service User, asignando dicho Host Group, un Grupo de Directorio Activo que englobe al personal de dicho departamento, asignar las tareas que deseamos que puedan hacer (ej: quizás no queramos que jueguen con los Snapshots), etc.
Bueno, que, ¿cambia o no cambia la cosa con Virtual Machine Manager 2008? Yo al menos, vistas las pruebas que he realizado con Virtual Machine Manager 2008 R2 y VMM Self-Service Portal, me he quedado bastante satisfecho, y además, le he encontrado el sentido al VMM Self-Service Portal, un componente de Virtual Machine Manager que antes pensaba que no era tan importante, y que ahora encuentro más que necesario en casi cualquier instalación de Virtual Machine Manager 2008.
Hasta aquí llega la parte de permisos con Virtual Machine Manager 2008, ya que el resto del artículo, continúa con los permisos de Hyper-V y Authorization Manager (AzMan). Continuamos.
Hyper-V y Authorization Manager (AzMan)
Para editar los Permisos de Hyper-V en un Host, lo primero que deberemos realizar es abrir la herramienta administrativa Authorization Manager, por ejemplo ejecutando AzMan.msc. Una vez que tenemos abierto el Authorization Manager, deberemos abrir el fichero de configuración (Authorization Store) que deseamos editar, utilizando la opción Open Authorization Manager, como se muestra en la siguiente pantalla capturada.
En el diálogo Open Authorization Store, surge una duda primordial ¿qué tenemos que abrir? ¿Un fichero de configuración? ¿Una base de datos SQL Server? ¿Una base de datos LDAP basada en Directorio Activo o en ADAM?
Pues bien, el Authorization Store utilizado por Hper-V se basa en un fichero de configuración XML. Aclarado esto, la siguiente duda es ¿Qué fichero XML es el utilizado por el Authorization Store de Hyper-V? Pues depende. Hyper-V de serie, utiliza el siguiente fichero XML:
C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.XML
Sin embargo, si estamos utilizando System Center Virtual Machine Manager, estaremos utilizando otro fichero XML para el Authorization Store, probablemente el siguiente:
C:\ProgramData\Microsoft\Virtual machine Manager\HyperVAuthStore.XML
Para asegurarnos, podemos consultar en el registro de Windows el valor de la clave StoreLocation, en la siguiente ubicación:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization
A continuación se muestra una pantalla capturada de dicha rama del registro, a modo de ejemplo.
La máquina con la que se han realizado las pruebas para escribir el presente artículo, fue inicialmente un Host Hyper-V independiente (en particular un Windows Server 2008 R2), y posteriormente fue añadido a dominio y gestionado a través de Virtual Machine Manager 2008 R2. Por ello, en nuestro caso de ejemplo, tenemos disponible ambos ficheros de configuración (aunque sólo un fichero XML es el que toma efecto, en este caso, el HyperVAuthStore.XML), que podemos abrir desde el Authorization Manager a modo de ejemplo, como se muestra en la siguiente pantalla capturada.
Como consecuencia de todo esto, en nuestro caso nos interesa editar el fichero HyperVAuthStore.XML, al tratarse de un Host gestionado por VMMM2008R2, y conforme nos indica la información que hemos revisado anteriormente en el Registro de Windows.
Editar los Permisos de Hyper-V con Authorization Manager (AzMan)
Lo primero, es importante conocer que Authorization Manager (AzMan) nos permite trabajar en dos modos: modo Desarrollador y modo Administrador. Habitualmente trabajaremos en modo Administrador, en el cual se puede hacer casi de todo, aunque eventualmente podemos necesitar entrar en el modo Desarrollador, el cuál se trata de un modo sin restricciones que permite realizar alguna cosilla más que el modo Administrador. Para cambiar el modo de operación de Authorization Manager (AzMan), deberemos acceder al diálogo Options, como se muestra en la siguiente pantalla capturada.
Al mostrarse el diálogo Options, podremos seleccionar el modo de operación deseado para Authorization Manager (AzMan), como se muestra a continuación.
Por otro lado, es importante tener en cuenta que tipos de objetos se pueden crear en Authorization Manager (AzMan):
- Operaciones (Operation Definition). Representan las acciones u operaciones básicas que se pueden realizar, es decir, las unidades mínimas de trabajo. Una Operación queda definida por un Nombre, una Descripción y un Número de Operación. En Hyper-V, por defecto existen 34 Operaciones pre-definidas, al menos en el caso de Windows Server 2008 R2, que es el caso tratado para la redacción del presente artículo.
- Tareas (Task Definitions). Una Tarea, permite agrupar varias Operaciones y/o Tareas. Por ejemplo, podríamos crear una Tarea denominada Connect, que incluya las Operaciones necesarias para que un usuario se pueda conectar al Host Hyper-V y ver sus Máquinas Virtuales, que serían las siguientes tres Operaciones: Allow Input to Virtual Machine, Allow Output from Virtual Machine, y Read Service Configuration. Así mismo, también podríamos crear una nueva Tarea denominada Read Only, que incluya la Tarea Connect recién creada, así como incluya también todas las Operaciones que permiten ver información de configuración de Hyper-V (las que empiezan por View). En Hyper-V, por defecto no existe ninguna Tarea pre-definida. Realmente, las Tareas son unos objetos opcionales, es decir, si nos facilita la vida crear alguna Tarea, pues bien, pero podemos vivir sin Tareas tan rícamente.
- Roles (Role Definitions). Un Role permite agrupar Operaciones y/o Tareas. Los Roles son la base de la asignación de permisos a los usuarios, es decir, un usuario le podemos asignar a uno o varios Roles. Es decir, si queremos asignar a un usuario alguna Operación o Tarea en particular, no podemos directamente, y estamos obligados a crear un Role (excepto que ya exista alguno que cumpla nuestros objetivos) asignando a dicho Role al usuario deseados y las Operaciones y/o Tareas deseadas. En Hyper-V, por defecto tan sólo existe un Role pre-definido: el Role Administrator.
En Authorization Manager (AzMan) también es posible crear Grupos (denominados Application Group), pero no entraremos en detalle sobre los mismos por simplificar.
La asignación de Roles a usuarios puede realizarse desde la carpeta o contenedor Role Assignments de Authorization Manager (AzMan). No tiene mayor misterio, por lo que no entraremos tampoco en detalles (es bastante trivial). Ojo, que podemos asignar o revocar, pero no podemos denegar (es decir, o asignamos o no asignamos, y punto).
Llegados a este punto, ya estamos preparados para delegar la administración de un Host Hyper-V, de tal modo, que ahora podríamos conseguir que un usuario pueda realizar sólo determinadas tareas sobre un Host Hyper-V, gracias a la creación de Roles. Para hacernos una idea, a continuación va un pantallazo con el muestrario de Operaciones disponibles en Hyper-V.
Pero claro, probablemente se nos pasará por la cabeza otra duda ¿Es posible en Hyper-V delegar la administración a nivel de Máquina Virtual, en vez de a nivel de Host? El tema, es que con lo que hemos visto hasta ahora, si permitimos a un usuario detener Máquinas Virtuales, podrá detener cualquier Máquina Virtual del Host. Sin embargo, quizás necesitemos ser algo más selectivos, de tal modo que necesitemos permitir ciertas acciones a ciertos usuarios pero sólo sobre ciertas Máquinas Virtuales (no sobre todas las Máquinas Virtuales). ¿Cómo podemos hacer esto? Para poder delegar la administración de Hyper-V a nivel de Máquina Virtual, es necesario crear Ámbitos (Scopes) en Authorization Manager, y asignar a cada Ámbito (Scope) las Máquinas Virtuales deseadas, para finalmente poder asignar permisos (perdón, Roles ;-) a nivel de cada Ámbito, y así conseguir el efecto deseado. Para mayor detalle, es aconsejable la lectura del post Seguridad en Hyper-V: Administrador de autorización para su correcta delegación Parte 3 Y FINAL, de Pablo Campos.
Enlaces de Interés
Para finalizar, aprovecho para incluir varios enlaces de interés relacionados con este tema (permisos en Hyper-V y Authorization Manager - AzMan), por un lado de TechNet, y por otro lado de Michael Michael, Ben Armstrong (Virtual PC Guy) y de Pablo Campos (muy bueno, y en español ;-). Aka va el repertorio de enlaces:
Como siempre, espero que os guste.
