Como mencionamos en nuestros posts anteriores, esto de las Managed Identities va en constante evolución por lo que este articulo se cala de maduro para actualizar unas cuantas cosas respecto a lo comentado anteriormente, así que vamos a ello:

Nueva forma de asignar permisos en el portal de Azure

En el articulo interior incluía varios pantallazos de como asignar un rol sobre un recurso (KeyVault/Azure Storage) a otro recurso (Function/Web App), pues bien, la forma ha cambiado ligeramente, pero esta vez para resumirlo he creado un pequeño video, aquí va:

Mejoras en el soporte para Service Bus

Como comentábamos anteriormente si uno quería usar Managed Identities en un Service Bus como trigger para un Azure Functions, tenia que usar la «sintaxis keyvault» desde los Application Settings, pero con la limitante de que esto solo funcionaba para Azure Functions Premium, pues bien ahora ya es posible usar MI como mecanismo de conexión/seguridad entre Azure Functions y Services, quedando la configuración así:

Dos detalles a considerar:
El atributo ya no se llama MiLeeBus.Connection sino MiLeeBus.Connection__fullyQualifiedNamespace.

El rol que el Service Bus debe otorgar al Azure Functions es el Azure Service Bus Data Receiver, como se ve aquí:

Mas detalles lo pueden ver en la Documentación, pero si quieren ver la aplicación practica revisen este código de mi proyecto de ejemplo en GitHub.

Soporte para Azure Blob Storage y Azure Functions (preview)

Algo que ha evolucionado bastante son las formas en que podemos interactuar con un Blob Storage desde un Azure Functions, vamos lo usual es que el storage definido en el Setting AzureWebJobsStorage sea el que se utilice como trigger para un Function basado en Blobs, pues bien llevemos el caso al extremo y veamos lo que hace falta para lograr lo siguiente:

• Que el Storage Account (A) usado como «soporte» para nuestro Function, y definido en AzureWebJobsStorage, solo sea referenciado por su nombre y no por un ConnectionString, puesto que la relación entre ambos elementos sea a través de Managed Identities. Notese que siempre debemos tener este setting en toda Function para que estas operen normalmente.
• Que un diferente Storage Account (B) actue como trigger de nuestro Function, y claro… que accedamos a este Storage sin ConnectionString, solo via Managed Identities.
• Que copiemos el archivo «input» de nuestro Function en la ruta destino usando… Managed Identities.

Creo que la idea quedo clara, ¿no? 😀

Para lo primero, en lugar de usar «AzureWebJobsStorage» como nombre del setting deberemos usar «AzureWebJobsStorage__accountName» y como valor solo deberemos usar el nombre del storage Account A, así: Sobre los permisos, nuestro Storage deberá asignar los roles Storage Account Contributor, Storage Blob Data Owner, Storage Queue Data Contributor de esta manera (1):

Ok, ya tenemos el storage «básico», ahora toca definir nuestro trigger personalizado, en este caso el nombre del setting cambia radicalmente, puesto que (por) ahora no deberemos agregar un setting, sino dos: ConnectionBlobTriggerOrigen__blobServiceUri y ConnectionBlobTriggerOrigen__queueServiceUri , queda claro que el sufijo (en mi caso «ConnectionBlobTriggerOrigen») deberá ser único, pues este sera el valor que se referenciara en nuestro código fuente (como pueden verlo aquí), y obviamente el valor de los settings (ruta calificada del storage B) también deberá ser el mismo, así:

Valores definidos (ningún key o connection string hasta ahora), resta definir los roles a asignar desde el Storage B, en este caso serán Storage Blob Data Owner y Storage Queue Data Contributor de esta manera:

Ok, ya hemos configurado el Storage «base» y el trigger, ahora toca configurar el Storage destino (a donde queremos copiar los archivos recibidos), pues bien en este caso el nombre del setting deberá ser ConnectionBlobTriggerDestino__serviceUri (nuevamente lo que importa es el sufijo y que respetemos el prefijo en el código fuente), así:

Con respecto al rol a usar, solo es necesario usar Storage Blob Data Owner, pero como en este caso particular estamos usando el mismo storage account (pero no la misma carpeta) quiere decir que ya lo tenemos configurado, siendo que para poder grabar en ese Storage deberemos usar un código mas o menos así.

var connectionTarget = new Uri(Environment.GetEnvironmentVariable("ConnectionBlobTriggerDestino__serviceUri") + "/" + folderTarget); 

......
BlobContainerClient containerTarget = new BlobContainerClient(connectionTarget, new DefaultAzureCredential());
containerTarget.CreateIfNotExists();

Y listo, ya tendremos lo necesario para empezar a trabajar plenamente con Managed Identities, reduciendo el uso de keys y connection strings en nuestras configuraciones, en este gráfico les resumo los roles empleados, espero que les haya sido de utilidad, espero sus comentarios!

Mas información:

• Grant permission to the identity
• Connecting to host storage with an identity (Preview)
• User-assigned managed identities for Azure Stream Analytics (preview) Si, otro servicio mas de Azure que ahora también se suma al soporte de Managed Identities.

(1) Los nombres de los settings pueden estar sujeto a cambios al tratarse de una funcionalidad en Preview, pero les ire informando periódicamente y actualizando el código fuente.