{"id":95225,"date":"2023-01-03T22:04:06","date_gmt":"2023-01-03T22:04:06","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=95225"},"modified":"2023-01-03T22:04:06","modified_gmt":"2023-01-03T22:04:06","slug":"azure-function-and-user-assigned-managed-identities","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/cloud\/azure\/azure-function-and-user-assigned-managed-identities\/","title":{"rendered":"Azure Function and User Assigned Managed Identities"},"content":{"rendered":"

Let’s talk about authentication between Azure Functions<\/strong> and resources used by Azure Functions<\/strong> and conclude with many poorly documented secrets about how to use User Assigned Managed Identity.\u00a0<\/strong>When we build Azure functions, they usually need to authenticate against other Azure resources: Azure SQL Database<\/strong>, Storage Accounts<\/strong>, Service Bus<\/strong> and many more.<\/p>\n

Each of these services have an authentication that we can call “Meh!”:<\/em> Azure SQL<\/strong> has SQL Standard Logins<\/strong>, storage accounts have SAS <\/strong>tokens, service bus, shared access keys and so on. These are not the safest methods possible. If the key leaks, you will have a security problem because anyone with the key will be able to access the resource.<\/p>\n

There are multiple solutions for this problem, some of them would pass through Key Vault, <\/strong>used to store secrets, keys and passwords. But let’s go directly to the best one: Remove the usage of keys at all.\u00a0<\/p>\n

How the Azure Function can authenticate against other services without using any key?<\/em><\/p>\n

We can assign an identity to the Azure Function and use this identity to authenticate on other resources. You can think about the identity as a special kind of Azure AD user. As with any other user, it can receive permissions in Azure resources, allowing your function to access the resources<\/p>\n

Instead of using a shared key in your system or configuration files, using an identity leaves it up to Azure to manage the access from the function to other resources. There will be no secret access key which could be exposed in your system.<\/p>\n

The two kinds of identity<\/h2>\n

The identity we set to a Function App (or other Azure Resource) is called a Managed Identity<\/strong>. There are two kinds of Managed Identity<\/strong>: The System Assigned Managed Identity<\/strong> and the User Assigned Managed Identity<\/strong>. <\/p>\n

First of all, it\u2019s important to understand that for both types, we are responsible to set the identity permissions, which is explained later.<\/p>\n

The System Assigned Managed Identity<\/strong> is the perfect example of the KISS<\/strong> principle (Keep It Simple): You just turn it on in an Azure Function. The identity is created with the same name as your function app. You can give permissions to this identity and that’s it, your function will be able to access the resources you need.<\/p>\n

When you delete the function app, the identity with all its permissions is deleted as well.<\/p>\n

The User Assigned Managed Identity<\/strong> is a bit more complex. Why would you need a more complex solution?<\/p>\n

If you have multiple Function Apps and all of them requires access to the same resources, using System Assigned Managed Identities becomes a problem. The management of permissions for each individual function identity is at least annoying, and it’s also prone to mistakes.<\/p>\n

The solution is to create a custom identity and assign the same identity to all Function Apps which requires the same set of permissions. In this way, you manage the permissions on a single identity, instead of many.<\/p>\n

This is the rule:<\/strong> If the permissions are needed by a single function, use a System Assigned Managed Identity and the identity lifecycle will be managed together the function lifecycle. If many functions need the same set of permissions, use a User Assigned Managed Identity and you will need to manage the permissions only for a single identity.<\/p>\n\n\n\n\n\n\n
\u00a0<\/td>\n\n

System Assigned Managed Identity<\/strong><\/p>\n<\/td>\n

\n

User Assigned Managed Identity<\/strong><\/p>\n<\/td>\n<\/tr>\n

\n

Usage<\/strong><\/p>\n<\/td>\n

\n

Used by one single function<\/p>\n<\/td>\n

\n

Can be assigned to multiple Function Apps and other cloud apps<\/p>\n<\/td>\n<\/tr>\n

\n

Lifecycle<\/strong><\/p>\n<\/td>\n

\n

Is created when turned on in the Function App and dropped together the Function App<\/p>\n<\/td>\n

\n

Created and dropped independently of the Function App. Someone needs to manage the identity<\/p>\n<\/td>\n<\/tr>\n

\n

How does it work<\/strong><\/p>\n<\/td>\n

\n

It simply works<\/p>\n<\/td>\n

\n

It may require variables or properties to work, but these will not contain any sensitive information<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Enabling System Assigned Managed Identity<\/h2>\n

As I mentioned before, these are very simple. You can just access the Identity tab and turn the identity on. The name of the identity is the name of the function app.<\/p>\n

<\/p>\n

\n

Enabling User Assigned Managed Identity<\/h2>\n

User Assigned Manage Identities have an independent life cycle. This means you need to create them directly from the Marketplace. To do this, locate the User Assigned Managed Identity in the marketplace resources and create it as illustrated on the following images:<\/p>\n

<\/p>\n

\n
\n

<\/p>\n

The creation itself is a generally simple matter of choosing the resource group and name of the identity. Consider the company standards for naming and resource group distribution. Some questions you should ask:<\/p>\n