Azure Managed Identity

 

Image by https://www.pexels.com/@cookiecutter/

In this blog, we discuss about the different options for service identity. Let's first lay down the objective of having a service identity for a service.

In a typical landscape, we have service to service communication. The diagram below shows a function app needs to read and write to blob storage, call Azure Cognitive Service, Azure Cognitive Search and read from Azure SQL service. In this example, we need to authorize the function app to make requests to these services. In short, authorization is needed for service to service communication.

To make thing simple, let's consider the case when we needed to authorize function app to read from a blob storage.

Option 1: Connection String of Blob Storage

Here, we set the connection string of the Blob Storage to a Azure Key Vault and have this string populated in function app's configuration. So that the function app can get it at runtime to read blob data.

This option is not ideal because

1. With connection string, the function app has permissions to perform all kind of operations on the blob storage. We are unable to restrict it to read operation
2. Azure Key Vault is needed to store the connection string for security reasons.
3. We need to update the connection string in Key Vault when the connection string changes.

Option 2: Shared Access Token

In the past, I have written blobs on Shared Access Token, this blog and another one. Essentially, it is a bearer token to grant the bearer to have permisssion(s) to perform operations for a limited period of time. Similar to Option 1, we need to store this token in a Azure Key Vault. With this option, we are unable to restrict the operation to read access. This option has the same #2 and #3 caveats as option #1.

Option 3: User Assigned Identity

In Azure Active Directory (AAD), we create an  (application) identity object and assign it to the function app. In this manner, the function app bears the identity of this object.

Next, we can grant blob storage read access to this identity. The advantage of this approach is that the identity to be assigned to multiple function applications and then all these applications have the same permissions. The only caveat is this identity object needs to be deleted once it is no longer needed that's when it is no longer assigned to any applications.

Option 4: Managed (Service) Identity (MSI)

Most of the Azure Services support MSI. For function app, we can enable it as show below.

Once it is enabled, we can grant blob storage read access to this identity. The advantage of this approach is that this identity is deleted once the function app is deleted. Similar to User Assigned Identity, there are no secrets exposed in the function application configuration values.

Conclusion

In most case, I like to go with the Managed Identity approach because it is simple, more secure and less maintenance (do not need to change secrets because there are no secrets stored in configuration)