Using User-assigned Managed Identities in Azure
In this guide, you will learn how to provision user-assigned managed identities, assign roles to them, and share them amongst various resources.
Oct 16, 2020 • 5 Minute Read
Introduction
Previous guides have covered using system assigned managed identities with Azure Stroage Blobs and using system assigned managed Identity with Azure SQL Database. However, Azure imposes a limit of 2,000 role assignments per Azure subscription. If you have a lot of Azure resources, each with their own individual system-assigned identity and granular role assignments, you can quickly run into this role assignment limit.
In this guide, you will learn how to provision user-assigned managed identities, assign roles to them, and share them amongst various resources. This can reduce administration costs since you'll have fewer service principals to manage.
Make sure you have the latest version of the Azure CLI to get started.
Creating User-assigned Identities
An easy way to begin working with user-assigned Identities is by using the Azure CLI. It allows you to create several Azure resources in only a few lines of code. This guide uses the Azure CLI with PowerShell.
$rg = "rg-pl-demo"
$id = "id-blogging-app"
$app = "app-blog"
$storage = "stblog"
az group create -l "australiaeast" -g $rg
$principalId = az identity create -g $rg -n $id -o tsv --query "id"
To begin, start by creating a resource group and a managed identity inside it. Resource groups allow you to organize and manage several Azure resources together. This includes assigning permissions or deleting all the resources in a group together.
A user-assigned identity is another resource that appears inside a resource group. This is convenient since the identity will automatically be deleted if you delete the resource group. In contrast, a service principal or app registration needs to be managed separately. The code above creates the user-assigned identity and saves the automatically generated principalId to a variable so that you can use it later.
Link User-assigned Identity to an Azure Resource
You can assign the identity you created to one or many resources. With the code snippet below you can create an Azure App Service Plan and App Service. Then, you use the identity you created above.
# create an app service plan and app service
$plan = "plan-blog"
$app = "web-blog-pl"
$runtime = 'dotnetcore"|"3.1'
az appservice plan create -g $rg -n $plan --is-linux --sku F1
az webapp create -g $rg -p $plan -n $app -r $runtime
# assign the id you created before
az webapp identity assign --identities $principalId -g $rg -n $app
$storage = "stblogpl"
az storage account create -g $rg -n $storage -l "australiaeast" --sku "Standard_LRS"
# assign roles
$principalId = az identity create -g $rg -n $id -o tsv --query "principalId"
az role assignment create --role "Storage Blob Data Contributor" --assignee $principalId
An App Service can have multiple user-assigned identities. In the example above, you assign one identity to the App Service and give it the Storage Blob Data Contributor role. When you assign this identity to another Azure resource, it will already have this role, thus reducing the total number of role assignments.
Update Your Code Using Managed Identity
As mentioned earlier, your App Service can have multiple identities assigned to it. In order for authentication to work correctly, you need to supply the clientId of the managed identity you created.
To do this, you can use Azure's new Azure.Identity nuget package.
services.AddAzureClients(cfg =>
{
var managedIdentityClientId = Configuration["ManagedIdentityClientId"];
var options = new DefaultAzureCredentialOptions
{
ManagedIdentityClientId = managedIdentityClientId
};
var id = new Azure.Identity.DefaultAzureCredential(options);
cfg.AddBlobServiceClient(Configuration.GetSection("Storage")).WithCredential(id);
});
The code above reads the ManagedIdentityClientId from configuration such as environment variable or AppSettings.json file. It then uses it as a parameter for the Azure.Identity.DefaultAzureCredential class.
DefaultAzureCredential is the simplest way to authenticate since it will iterate over the various authentication flows automatically. When you run this code on your development machine, it will use your Visual Studio or Azure CLI credentials. In the App Service environment it will use managed identity.
Note: When you assign the identity and roles to it, it may take a few minutes to update. If you are having issues, try to redeploy the app and restart the App Service instance.
Conclusion
User-assigned managed identities simplify security since you don't need to manage credentials. Not all resources are supported at this time, however, they enable access to a growing list of Azure resources that support Azure AD authentication. You can learn more by reading about the services that support managed identities for Azure Resources in Microsoft's documentation.