Azure Functions and Managed Identity: More Secrets

I wrote about Managed Identity Secrets a few weeks ago, but since that article was published I made new interesting discoveries to add more to these secrets.

The combination of possibilities is considerable, and I faced two new situations I hadn’t faced before. Let’s discover the new secrets.

 

Storage Accounts and Triggers

The storage account triggers depend on configurations in the Function/App to stablish the connection.

This configuration is intended to contain a connection string built with a storage account key or SAS key.

When we want to use Managed Identities, the configuration needs to be different. The name we use in the trigger code becomes only the prefix for the configuration.

We need different configuration entries for the blob service and the queue service, each one containing the full address of the service. In this way, the trigger understands we intend to use Managed Identity authentication, instead of key/SAS authentication.

These are the names you should use for the configuration values:

<CONNECTION_NAME_PREFIX>__blobServiceUri

<CONNECTION_NAME_PREFIX>__queueServiceUri

Aplicativo

Descrição gerada automaticamente com confiança baixa

Reference: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-blob-trigger?tabs=in-process%2Cextensionv5&pivots=programming-language-csharp

Blobs Requires Queues

When you use keys, usually the connection string has the endpoint for all the services, blobs and queues.

When using managed identities, as explained above, the endpoint is in two different configurations. This brings up another secret: When connecting to a blob using the blob trigger, the queue connection is required as well.

The blob trigger handles failures using a queue, for this reason, when using the blob trigger the queue endpoint needs to be specified as well.

 

Azure SQL and User Managed Identities

The connection string for System Managed Identities is simple, as explained on the first article.

When using User Assigned Managed Identity, on the other hand, we need an additional parameter on the connection string. We need to specify the Client Id of the User Assigned Managed Identity we intend to use.

The Client Id is specified as the User Id. The connection string will be like this:

Server=DBServer.database.windows.net; Authentication=Active Directory Managed Identity; Initial Catalog=adventure;User Id=19fad297-5cf8-4fb9-9601-26d38d7854aa

Interface gráfica do usuário, Texto

Descrição gerada automaticamente com confiança média

This also applies to SQL Server 2022, which supports Azure AD Authentication.

 

Bonus: Using configurations to customize trigger parameters

Some trigger parameters are not so obviously configurable. For example, the queue name when connecting to a storage queue.

You wouldn’t like to have this kind of value tied in your code. The flexibility to change the queue name, for example, is very welcome. We can use different queue names for development, UAT and production environment, for example.

The solution is simple: you can use the ‘%’ symbol to retrieve a configuration value as a trigger parameter.

For example, a queue trigger would become like this:

[QueueTrigger(“%queuenameconfig%”, Connection = “inputStorage”)]

The connection parameter is retrieved from the configuration naturally, with the additional details explained above about managed identities. The queue name, on the other hand, will only the retrieved from configuration if transformed in a variable using the ‘%’ symbol.

 

Conclusion

Using Managed Identities on PAAS services can be full of tricks. Don’t assume a service doesn’t support it, you may be missing a configuration.