SetValue.NETSetValue.NET

Managed Identities en Logic Apps

July 26, 2020

Generic badge

Las Logic Apps disponen de innumerables conectores que, mediante "cuatro clicks", te permiten realizar operaciones que en el caso de tener que programarlas por uno mismo, pueden suponer trabajo de días o semanas, sin embargo, esta aceleración en el desarrollo, se sustenta en operaciones que requieren la intervención manual, o la asignación de unas credenciales dentro del Portal. Sí bien es cierto, que una vez creadas las API Connection se resuelve el problema, en un entorno de producción, el usuario desarrollador no tiene por qué tener acceso a los recursos en el Portal de Azure.

Managed Identity

Para resolver este tipo de dificultades tenemos las Managed Identity, un servicio de Azure AD que consiste en un registro de aplicación que abstrae y facilita el acceso a los recursos de Azure en el que es autorizado.

Nos encontramos con dos tipos de Managed Identity:

  • System-Assigned Managed Identity. Son directamente habilitadas por una instancia de un servicio de Azure, cuando se habilitan se crea un registro en el Azure AD y sus credenciales quedan configuradas en el recurso en el que se ha creado. Su ciclo de vida queda supeditado al ciclo de vida del recurso de Azure.
  • User-Assigned Managed Identity. Son definidas de forma independiente a cualquier servicio de Azure, al crearse se define un registro de aplicación en Azure AD y puede ser asignado a uno o más servicios de Azure. Su ciclo de vida no depende de los recursos en los que está asignada.

Let's go

Las Logic Apps son unos workflow que se pueden desarrollar directamente en el Portal de Azure y que, gracias a toda la funcionalidad de caja que traen los conectores, permiten desarrollar una solución en minutos u horas, sin embargo, desarrollar estos flujos desde el Portal no es una buena práctica, pues no todos los miembros de un equipo de desarrollo tienen por qué tener el mismo nivel o si quiera acceso a un grupo de recursos o una suscripción. "Otro problema" que hay en este sentido, es que las Logic Apps se versionan en el Portal, puedes crear la solución y cada guardado mantiene una versión que te permite volver y comparar con una versión anterior, pero esto nos aleja de un repositorio de Git dónde debería estar todas las versiones de código de la solución.

Requisitos

Microsoft provee estas dos extensiones para poder trabajar las Logic Apps desde Visual Studio 2019, Visual Studio Code, y versiones anteriores 2017 o 2015.

Una vez instalada en el IDE de nuestra preferencia, la edición de las Logic Apps se puede versionar en un repositorio de código.

Recursos

Para este ejemplo, en el Portal, en un nuevo grupo de recursos, creamos:

  • Logic App. Es el flujo que va a realizar la conexión al Key Vault para recuperar un secreto y al Storage Account para agregar un mensaje a una cola.
  • Key Vault. Depositará el o los secretos a los que puede acceder la Managed Identity de la Logic App
  • Storage Account. Gestionará en una cola los mensajes que le envíe la Logic App.

Resources

Dentro del blade de Identity de la Logic App, activamos System Managed Identity.

System Managed Identity

Tras crear la identidad gestionada, en las Access policies del Key Vault, agregamos la identidad de la Logic App para que pueda ver los secretos. Y agregamos un nuevo secreto con un texto aleatorio.

Access Policies

Ahora, en la Storage Account, en el blade de Access control (IAM) asignamos el rol de Storage Queue Data Contributor, después en Queues, hacemos Switch to Azure AD User Account en Authentication method y creamos una nueva cola llamada log.

Switch to Azure AD Account

Desarrollo

En Visual Studio, creamos un nuevo proyecto de tipo Azure Resource Group.

New Azure Resource Group

Seleccionamos de las Visual Studio Templates, la plantilla de Logic Apps.

Logic App

Una vez se ha terminado de cargar el nuevo proyecto, se habrán generado un fichero PowerShell junto con dos ficheros JSON, uno de ellos es la definición de la Logic App y el otro es el fichero de parámetros.

En el fichero de definición de la Logic App, establecemos en "Resources" que vamos a utilizar System Managed Identity.

      "identity": {
        "type": "SystemAssigned"
      }

Además de poder modificar la definición de la Logic Apps desde el JSON, también podemos acceder en modo diseñador con la opción Open With Logic App Designer. Esta opción nos solicitará una suscripción y un grupo de recursos, seleccionamos el Resource Group que contiene la Logic App con la Managed Identity.

Logic App Open With Designer

Una vez, seleccionado el grupo, tendremos la misma experiencia de diseño de Logic Apps que hay en el portal.

Logic App Designer

Agregamos un trigger de tipo HTTP request is received, que espere un método GET y con este esquema en el cuerpo.

  • Method: GET
  • Relative path: /secrets/{secretName}
{
    "type": "object",
    "properties": {
        "secretName": {
            "type": "string"
        }
    }
}

Trigger

Seguimos agregando una action de tipo HTTP y le configuramos:

  • Method: GET
  • URI: Como expresión, agregamos concat('https://demomikv.vault.azure.net/secrets/', triggerOutputs()['relativePathParameters']['secretName'])(donde demomikv es el nombre de nuestro Key Vault)
  • Queries:
    • Key: api-version
    • Value: 2016-10-01
  • Authentication: Agregamos el parámetro, y le definimos:
    • Authentication type: Managed Identity
    • Managed Identity: System Assigned Managed Identity
    • Audience: https://vault.azure.net

Get Secret

Renombramos la action, y marcamos en los settings que su output esté cifrado.

Secure Outputs

Después, creamos otra action de tipo HTTP para realizar por ejemplo un log de las llamadas que recibe la Logic App, esto realmente se hace a modo de ejemplo, para introducir un registro con la Managed Identity en un el Storage Account.

@{body('Get_Secret')} ``` - **Authentication**: Agregamos el parámetro, y le definimos: - **Authentication type**: Managed Identity - **Managed Identity**: System Assigned Managed Identity - **Audience**: https://storage.azure.net

Add log

Agregamos una nueva action para devolver el secreto al peticionario que ha desencadenado la Logic App.

Response

Publicación

Para realizar la publicación, el primer paso es definir el nombre que tiene la Logic App, para ello, en el fichero de parámetros, modificamos el JSON de esta forma:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "logicAppName": {
      "value": "DemoMIla"
    }
  }
}

En el menú contextual del proyecto de tipo Azure Resource Group, podemos seleccionar la opción Deploy para publicar la Logic App y desplegamos.

Deploy Logic App

Este proceso desencadena el PowerShell y publica los ARM que hay en el proyecto.

Deployed

Pruebas

Finalmente, una vez está publicada la Logic App en el portal, en el trigger podemos obtener la url a la que debemos invocar con el método GET. En Postman podemos hacer una prueba invocando esta url y pidiéndole el secreto que habíamos creado en el Key Vault.

Postman

Tras obtener el secreto, un nuevo mensaje está publicado en la cola del Storage, aunque es un ejemplo, pues realmente no es necesario almacenar un mensaje en la cola de un Storage cuando solicitas un secreto, es un ejemplo de cómo también se puede acceder a la Storage Account con la Managed Identity. Podríamos seguir procesando esa cola y realizando alguna acción, como por ejemplo rotar el valor de ese secreto con cada petición.

Buy Me A Coffee