Service Principal vs Managed Identities, parte 2
En el artículo anterior hablamos de los service principals. Dimos alta una cuenta que la usábamos para crear un recurso en la consola de PowerShell.
En este siguiente post vamos a hablar de un «primo» de los service principal. Estamos hablando de la «managed identities«.
Qué es una «managed identity»
Por así decirlo es similar a un service principal ya que va a representar una identidad en la que no hay detrás un usuario de carne y hueso. Pero la gran diferencia es que en este caso me olvido de gestionar la clave de esta identidad como con el service principal.
Características:
- No hay credenciales. Es totalmente «desatendido».
- En ningún caso esa «contraseña» (token de Azure AD) será accesible por nuestra parte
- Podrán ser utilizado por cualquier recurso que sea compatible
- No implican ningún coste adicional
Tipos de Manaded Identity
Funcionalmente harán lo mismo pero las vamos a diferenciar según el ciclo de vida de la identidad.
- System-Assigned: Totalmente desatendido. Se crea una identidad en Azure AD para representar al recurso. Si el recurso se borra, automáticamente se borra la identidad. Sólo se puede usar en un único recurso. Ejemplo: servidor1
- User-Assigned: Yo creo una identidad y luego se la asigno al recurso. Se pueden usar la misma identidad en varios recursos. Nos puede servir si tenemos alguna polítca de nomenclatura en la empresa para la cuenta. Ejemplo: miservidor1
DEMO
Para la DEMO vamos a usar una máquina virtual.
Nos vamos a la VM y en el blade de la derecha hacemos un filtro para buscar por «ide….», y nos va a aparecer «Identity» y al pinchar vemos las dos opciones que comentábamos antes:
- System assigned
- User assigned
Vamos a habilitar la primera pulsando en «ON» y guardamos:
Nos aparece el siguiente mensaje:
Al aceptar, nos aparece un nuevo mensaje:
This resource is registered with Azure Active Directory. The managed identity can be configured to allow access to other resources. Be careful when making changes to the access settings for the managed identity because it can result in failures. Learn more
Si queremos localizar la identidad, lo haremos desde «Enterprise applications» y seguido cambiamos el filtro:
Una vez aplicado el filtro:
Habíamos visto que esta identidad nos permitiría que la VM tuviera una identidad en Azure AD. Esto nos va a permitir, por ejemplo, facilitarle unos permisos de RBAC en un grupo de recursos.
Si borramos la VM veremos que la identidad de borra automáticamente:
Y ya no es visible:
Y por hoy suficiente, hemos creado una identidad administrada de tipo sistema y la hemos borrado. En el siguiente post veremos qué sucede con una identidad de tipo usuario.
Nos vemos en el siguiente post.
