En otra entrega más por este fabuloso y cambiante mundo del Cloud Computing, me gustaría presentaros un reto, el cual, en el momento que estoy escribiendo esta entrada 2 de los servicios que voy a enseñar se encuentran en modo Preview, pero… ¿quién dice que la proactividad e investigación no deba estar por delante para recomendar lo mejor a tus clientes, y más, cuando tratamos temas de seguridad?

¿Cuántas veces no hemos escrito credenciales hardcodeadas en un script/app al picar el código y se nos ha quedado ahí al compartirlo o simplemente al llevarlo a producción?

Por suerte a la hora de compartir, tenemos gracias a GIT un archivo brillante denominado .gitignore en el cual podemos almacenar nuestras credenciales y no se sincronizarán, pero, ¿y si quisiéramos dejar corriendo una aplicación o script en modo serverless? ¿y si me comprometen el acceso a la webapp o símplemente me consiguen impersonar el usuario?

Ya es hora de cambiar eso, así que, en esta entrada, vamos a mostrar la posibilidad de olvidarnos de credenciales en Azure Functions gracias a Management Service Identity y Key Vaults.

Para aquel o aquella que no sepa de qué hablo, pongo un poco en contexto:

• Azure Functions: Nos permite ejecutar código a petición sin necesidad de aprovisionar ni administrar explícitamente la infraestructura, ese código puede ser ejecutado mediante llamadas webhook, scheduler, etc.

Más info: https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview

• Managed Service Identity: Proporciona a los servicios de Azure una identidad administrada automáticamente en Azure Active Directory.

Más info y servicios disponibles actualmente: https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/services-support-msi

• Key Vaults: Ayuda a proteger claves criptográficas y secretos usados por servicios y aplicaciones en la nube a través del uso de claves que están protegidas por módulos de seguridad de hardware (HSM).

Más info: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-whatis

Ahora que nos hemos puesto un poco en contexto, comentar que los dos servicios en Preview actualmente son: Azure Functions haciendo uso de PowerShell y MSI (Managed Service Identity).

Pues bien, es hora de ponernos manos a la obra, mediante los siguientes pasos:

• Creamos nuestra aplicación de identidad administrada habilitando Managed Service Identity en nuestra función, dentro del mismo blade de Azure Functions:

• Una vez creada, procedemos a dar permisos a nuestra aplicación administrada sobre las políticas de acceso de nuestro Key Vault para poder así obtener los secretos:

• Imaginemos que hemos insertado 2 Secrets manualmente, por ejemplo, appId y appKey para que otro SPN realice la autenticación con Azure en nuestra aplicación, a continuación mostraremos el caso de appId:

• En este último punto, veremos cómo se realizaría la parte del código en PowerShell, pero de igual manera, al tratarse de un GET a la REST API de Azure podemos realizar de manera similar la llamada para obtener nuestro secreto deseado con cualquier lenguaje que soporte Azure Functions:

$vaultName = "z0"
$vaultSecretName = "appId"

$tokenAuthURI = $Env:MSI_ENDPOINT + "?resource=https://vault.azure.net&api-version=2017-09-01"
$tokenResponse = Invoke-RestMethod -Method Get -Headers @{"Secret"="$env:MSI_SECRET"} -Uri $tokenAuthURI
$accessToken = $tokenResponse.access_token
Write-Output $accessToken

$headers = @{ 'Authorization' = "Bearer $accessToken" }
$queryUrl = "https://$vaultName.vault.azure.net/secrets/" +$vaultSecretName + "?api-version=2016-10-01"

$keyResponse = Invoke-RestMethod -Method GET -Uri $queryUrl -Headers $headers

Write-Output $KeyResponse.value

Si nos fijamos en el código, estamos solicitando nuestro token a un audience diferente (https://vault.azure.net), nos ocurre algo parecido a la entrada anterior, debemos de tenerlo en cuenta para no llamar al audience por defecto.

Si decodificamos nuestro token con la herramienta proporcionada por jwt.io podemos ver que la estructura es correcta:

En la variable $KeyResponse.value ya tendríamos nuestro secret AppId, podemos ver su valor si activamos el trigger de la función:

No olvidéis que la seguridad sustenta uno de los pilares principales de toda empresa y desarrollador, saquemos ese perfil DevOps que llevamos dentro 

Después de un tiempo sin escribir debido a motivos laborales y el máster de ciberseguridad a punto de finalizar, nos aventuraremos a realizar algo en lo que no encontré mucha documentación en la web, pero necesario para mejorar la seguridad en los mismos y centralizar la autenticación en AAD, exactamente explicaré cómo realizar una autenticación mediante un Service Principal en Azure SQL haciendo uso de nuestra gran arma: PowerShell.

Debemos de tener generado nuestro Service Principal, en caso de que así no sea, es tan sencillo como dirigirnos a Azure Active Directory y registrar una nueva aplicación de tipo Web App/API indicando un URI Endpoint cualquiera:

Apuntamos el Application Id que nos genera, además debemos de obtener un Secret, para ello nos vamos al apartado de Keys y generamos 1 con la fecha de expiración que deseemos apuntando ambos valores:

Vale, pero… ¿Cómo va a reconocer el acceso mi Azure SQL si no lo he indicado en ningún sitio?

¡Vamos con ello!

Entramos en nuestra DB con un usuario con autenticación básica que sea administrador de la DB y ejecutamos la siguiente query T-SQL para crear el usuario desde un proveedor externo, le ponemos el rol que nos interese, en nuestro caso lo dejamos como db_owner:

CREATE USER [ApplicationName] FROM EXTERNAL PROVIDER
GO
ALTER ROLE db_owner ADD MEMBER[ApplicationName]

Para llegar a nuestro objetivo, tenemos que estudiar las diferentes posibilidades:

• Invoke-SQLCMD: No permite modificar en el ConnectionString la posibilidad de añadirle un token de acceso, además, el campo Authentication cuenta con:
  • Autenticación integrada (hace uso de SSO y nuestro cliente unido a dominio).
  • Autenticación mediante Azure AD con Usuario/Contraseña.
  • Autenticación básica SQL Server.
• ADO.NET: Si estudiamos la conexión que se realiza desde C# (mucho más documentada, todo hay que decirlo), podemos observar que tenemos ya algo que nos puede servir dentro de las propiedades de la clase System.Data.SqlClient.SqlConnection  AccessToken.

Por lo tanto, tenemos claro el camino que tenemos que seguir, ahora tenemos otras 2 opciones, ¿me compilo una librería en C# y realizo la llamada posteriormente o intentamos hacer uso de la clase de manera directa desde PowerShell?

Por temas de performance, vamos a intentar ir por la segunda opción, ¿pero cómo obtengo Access Token si además me vendrá cifrado y en JSON?

Para ello, en primer lugar autenticaríamos con nuestro Service Principal que podría obtener el Secret de nuestro Service Principal de un Azure Key Vault por ejemplo, evitando así tener passwords hardcoded:

$securePassword = ConvertTo-SecureString $appKey -AsPlainText -Force
$secureCredential = New-Object System.Management.Automation.PSCredential($appId, $securePassword)
Connect-AzureRmAccount -ServicePrincipal -Credential $secureCredential -TenantId $tenantId -SubscriptionId $subscriptionId

A continuación, procedemos a generar la función que nos devuelva nuestro Access Token solicitándolo al audience correspondiente (https://database.windows.net/“) mediante una petición de REST API diréctamente a Azure, aquí es necesario que le pasemos en las variables correspondientes el Application Id y Secret Key:

function Get-AccessToken{
    $TokenEndpoint = {https://login.windows.net/{0}/oauth2/token} -f $tenantId 
    $ARMResource = "https://database.windows.net/";

    $Body = @{
            'resource'= $ARMResource
            'client_id' = $appId
            'grant_type' = 'client_credentials'
            'client_secret' = $appKey
    }
    $params = @{
        ContentType = 'application/x-www-form-urlencoded'
        Headers = @{'accept'='application/json'}
        Body = $Body
        Method = 'Post'
        URI = $TokenEndpoint
    }
    $token = Invoke-RestMethod @params
    return $token.access_token
}

Una vez que tenemos nuestro token, podemos comprobar que es correcto decodificándolo con jwt.io, tenemos que obtener algo parecido a:

Por último, nos creamos la función de conexión que lanzará la query que le pasemos como parámetro contra Azure SQL y cerrará la conexión para evitar tener sockets abiertos, aquí es necesario que añadamos el nombre del servidor SQL y la DB a la cual queremos conectar:

function SQLConnection {
    param(
     [string]$query
    )
    $ConnectionString = 'Server=<YOUR SQL SERVER>.database.windows.net;Database=<YOUR DB>;Integrated Security=False;'
    $connection = New-Object -TypeName System.Data.SqlClient.SqlConnection($ConnectionString)
    $connection.AccessToken = Get-AccessToken
    $connection.Open()
    $cmd=new-object system.Data.SqlClient.SqlCommand($query,$connection)
    $cmd.CommandTimeout = 30
    $DataSet = New-Object system.Data.DataSet
    $Adapter = New-Object system.Data.SqlClient.SqlDataAdapter($cmd)
    [void]$Adapter.fill($DataSet)
    $value = $DataSet.Tables[0]
    $connection.Close()
    return $value
}

¡Espero que hayáis aprendido tanto como yo al escribir esta entrada! 

Me gustaría comenzar esta entrada poniéndonos todos en contexto (nunca mejor dicho) y siguiendo lo comentado en la primera entrada: Hi World!

A final de septiembre de 2017, Microsoft incluyó un cmdlet muy interesante: Azure Context Autosave, éste funciona desde la versión 4.4.0 del módulo de AzureRM de PowerShell, en el momento que estoy escribiendo estas líneas, estamos ya por la versión 5.4.0.

Ante el tedioso motivo de tener que insertar la credencial cada vez que queremos interactuar con nuestras suscripciones de Azure o de nuestros clientes al tener varias cuentas, tenemos que hacer uso en numerosas ocasiones de:

Login-AzureRmAccount

En este ejemplo, vamos a enseñar cómo hacer uso del nuevo cmdlet para 2 cuentas diferentes gracias a las plantillas JSON de ARM siguiendo los siguientes pasos:

• Habilitamos AzureRM Context, que nos guardará la información en: %AppData%\Roaming\Windows Azure PowerShell para ello, ejecutamos el siguiente cmdlet:

Enable-AzureRmContextAutosave

• Agregamos las 2 cuentas mediante el cmdlet:

Connect-AzureRmAccount

• Nos fijamos en el nombre de los 2 contextos que se han creado en: %AppData%\Roaming\Windows Azure PowerShell\AzureRmContext.json ó también ejecutando el siguiente cmdlet:

Get-AzureRMContext -ListAvailable

• Renombramos el contexto con un nombre familiar, como podemos ver en la imagen de más arriba se han renombrado ambos contextos, uno pertenece a “Yoda” y el otro personal “JoseLCAguilar“, para ello hacemos uso del siguiente cmdlet en ambos contextos:

Rename-AzureRMContext "NombreOriginal" "NombreFamiliar"

• Para cambiar de un contexto a otro, símplemente ejecutamos lo siguiente:

Select-AzureRMContext "NombreFamiliar"

• Por último, para eliminar un contexto, podemos hacer uso de:

Remove-AzureRmAccount -ContextName "NombreDeContexto"

Si nos fijamos, al abrir y cerrar la sesión de PowerShell, ¡voilá! podremos ver que automágicamente el equipo nos coge el último contexto usado y podemos hacer uso de todos los cmdlets de Azure sin tener que escribir las credenciales una y otra vez en nuestra consola de PowerShell.

Podéis encontrar más info aquí.