¡Hola de nuevo! si te perdiste la primera parte, te dejo un link donde vemos el porque usar Azure desde linea de comando, y la forma de instalarlo.
En esta ocasión les voy a comentar algo que deje pendiente al final del post anterior, y es como loguear a Azure sin la interacción del usuario. Esto es importante porque si tenemos procesos automatizados, dado que nuestros scripts deberían poder autenticarse en Azure sin la necesidad de que haya alguien ingresando manualmente las contraseñas. Hay varias formas de hacer esto, les voy a comentar 2 que son las que considero más prácticas:
- Logueo mediante contexto de Azure
- Logueo mediante Service Principal
Logueo mediante contexto de Azure.
En este caso, lo que se hace es almacenar un token de autenticacion de Azure en un archivo json. Luego al comienzo de cada script podemos cargar ese archivo json y eso automáticamente nos autenticará contra Azure. Es muy práctico de implementar, pero tiene una desventaja importante: el token vence luego de 30 días. Aun así, nos puede salvar de apuros hasta que tengamos una solución mas robusta.
Lo primero que debemos hacer para almacenar este token, es abrir Powershell y loguear de modo manual como ya hemos visto en episodios anteriores:
Login-AzureRmAccount
Luego, debemos elegir donde se almacenará y como se llamará este archivo json que contendrá el token, puede ser cualquier carpeta y cualquier nombre. Como ya hemos hecho antes, almacenamos la ruta en una variable y luego llamamos al cmdlet correspondiente:
$ruta = "C:/Ruta/Al/Archivo/AzureAuth.json"
Save-AzureRmContext -Path $ruta
De este modo, habremos generado un archivo json que contiene un token para autenticarnos sin interacción del usuario en Azure. Ahora para que nuestros scripts sean 100% autónomos, podemos reemplazar la parte de Login-AzureRmAccount por esto:
$ruta = "C:/Ruta/Al/Archivo/AzureAuth.json"
Import-AzureRmContext -Path $ruta
¡Así de sencillo! Al ejecutar esto ya estaremos autenticados. La gran contra que tiene este método, como ya comente, es que el token expira luego de un mes y hay que regenerarlo. Esto implica que alguien debe loguear manualmente y guardar el contexto nuevamente para que sea válido el token.
Logueo mediante Service Principal
Para evitar tener problemas con el contexto y su token, lo recomendable es usar este método. Un service principal es un usuario de servicio, que nos permitirá administrar recursos de Azure para los cuales tenga permisos asignados. Este método lleva unos pasos extra, pero nos da la opción de programar scripts que no tienen fecha de caducidad, y ademas es más seguro porque al loguear solo tendremos permisos para administrar algunos recursos sobre los que tenga permiso el service principal, y no sobre todos los que disponga un usuario en particular como en el caso del contexto.
Para loguear con un service principal, el primer paso es tener uno. Para crear uno, tenemos la opción de hacerlo mediante el portal o mediante Powershell con el cmdlet New-AzureRmADServicePrincipal. Como es algo que haremos solo una vez, explicaré como hacerlo en el portal de modo gráfico. Para esto, dentro del portal vamos a la opción Azure Active Directory en la parte izquierda de la pantalla. Una vez ahí, elegimos App Registrations, y luego en el símbolo +, que dice New Registration.
Al momento de crear un service principal solo debemos asignarle un nombre, procura que sea un nombre que describa su función, o a que recursos tendrá acceso. Luego de ponerle un nombre damos click en Register.
Luego de crearlo, ya podremos asignarle permisos a nuestro service principal a los recursos que queremos que pueda administrar desde Access Control (IAM) en el correspondiente recurso, como si se tratara de un usuario más. Después de darle los permisos correspondientes, tomaremos nota de algunos valores que necesitaremos al momento de autenticarnos en nuestro script, estos valores son: TenantId, ApplicationId, y SecretId.
A continuación, te explico como obtener cada uno:
- ApplicationId: lo podemos obtener dentro de Azure Active Directory -> App Registration -> Selecciona el service principal creado. Nos mostrará algunos códigos, pero el que nos interesa en este caso es este "Application (client) ID".
- SecretId: en la misma ventana de donde sacamos el ApplicationId, podemos ver a la izquierda "Certificates & secrets", clickeamos ahí. Después vamos a "New Client Secret", asignamos un nombre a nuestro secret, y damos click en "Add". Esto generará un nuevo secreto, ¡asegúrate de guardarlo bien! Una vez que cierres esta ventana no podrás volver a obtenerlo!!
- TenantId: este es más sencillo, lo obtenemos de Azure Active Directory -> Properties -> Directory Id.
Entonces, ahora ya tenemos nuestro service principal creado, con sus permisos y tenemos los datos que necesitamos para autenticarnos en nuestro script. ¡Manos a la obra! Como hemos hecho con anterioridad, almacenaremos en variables y luego las llamaremos. El código es un poco más largo esta vez, pero no mucho:
$ServPpalSecret = "ServicePrincipalSecret"
$ServPpalAppId = "ServicePrincipalAppId"
$TenantId = "DirectoryId"$secpasswd = ConvertTo-SecureString $ServPpalSecret -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ($ServPpalAppId, $secpasswd)Login-AzureRmAccount -Credential $creds -ServicePrincipal -TenantId $TenantId
¡Listo! Al ejecutar éstas lineas nuestro script estará logueado con este service principal de forma 100% autónoma! Ahora si podremos usar nuestros scripts como runbooks en Azure Automation, o almacenarlos como .ps1 y llamarlos desde el programador de tareas de Windows (o cron desde Linux, si usamos Powershell Core), sin preocuparnos por fechas de caducidad de tokens, con la tranquilidad de que no requerirán ninguna interacción por parte del usuario.
Espero que les haya gustado, ¡¡no se pierdan el próximo episodio!! :)
Escrito por Martín Zurita.