Service Principal vs Managed Identities, parte 1

En ADDS teníamos las llamadas «service accounts«. Unas cuentas que podríamos usar para identificar y autenticar un servicio, arrancar un proceso, etc.

En el ecosistema Azure, tenemos algunas identidades similares. En este post te hablo de los «service principals«.

Qué es un service principal

Una aplicación que necesita acceder a recursos necesita ser representada de algún modo. Es lo que llamamos service principal.

Tendremos diferentes tipos pero hoy vamos a trabajar con el de aplicación. Un service principal de tipo aplicación se crea para que sea empleada en representación de una aplicación. Siendo una identidad única y específica para el tenant en el que funcionará.

Listar service principals

A diferencia de las cuentas de servicio de ADDS donde desde la propia consola de AD accedíamos a los usuarios, grupos, service accounts, etc. en Azure las encontraremos en una sección separada de los usuarios, lo vemos en «App registrations«.

En Azure:

DEMO

En este ejercicio vamos a crear un service principal que usaremos en nuestra consola de Powershell para crear un recurso en Azure.

Creando un SP

$spDisplayName = "spPowershell"
$sp = New-AzADServicePrincipal -DisplayName $spDisplayName -Role "Contributor"

Si quieres saber más sobre el cmdlet utilizado, navega hacia la documentación oficial con New-AzADServicePrincipal.

Nos quedamos con la salida y nos apuntamos estos valores que utilizaremos en el siguiente paso:

$sp.AppId
1d2aedab-7ab7-42f2-85a0-11b3b0c12e33
$sp.PasswordCredentials.SecretText
O0A8Q~dD5eYY~Zi~AQ4eUNRUg_JXShFq4LOhPdoT

Al ejecutar:

Si nos vamos al RBAC de la suscripción veremos el service principal con el rol que acabamos de definir.

Service Principal con Powersehell

Para poder autenticar la consola de Powershell con el service principal, lo haremos del siguiente modo:

$pass = "O0A8Q~dD5eYY~Zi~AQ4eUNRUg_JXShFq4LOhPdoT"
$tenantId = "xxx"
$AppId = "1d2aedab-7ab7-42f2-85a0-11b3b0c12e33"

$passwd = ConvertTo-SecureString $pass -AsPlainText -Force
$pscredential = New-Object System.Management.Automation.PSCredential($AppId , $passwd)
Connect-AzAccount -ServicePrincipal -Credential $pscredential -Tenant $tenantId

Al ejecutar:

Ahora vamos a generar un grupo de recursos y un recurso simple:

New-AzResourceGroup -Name RG01 -Location "west europe"
New-AzStorageAccount -ResourceGroupName RG01  -Name storageaccountsrvprin -Location "west europe" -SkuName Standard_GRS

Si nos vamos al log de actividades, veremos que la identidad que ha creado este recurso es el service principal y no un usuario:

Y hasta ahí la pequeña demo, en el siguiente post hablaremos de las identidades administradas, para saber qué son y ver algún ejemplo de uso.

Un saludo.