Azure Managed Identities: User vs System Assigned

Overview

It is easy to get lost in the world of Azure identities. There are so many options and confusing nomenclatures it is easy to get lost. At a high level there are System Assigned Identities, User Assigned Identities, Service Principals, and even Shared Access Signature (SAS) as ways to access Azure Resources. Here is in order preference what I typically recommend for customers. I’ll go into details mainly on Azure Managed Identities: User vs System Assigned which are the ones recommended by Microsoft:

Let me take a minute here to explain some nomenclature differences you might see/hear. Managed System Identities (MSI) is a broader term that encompasses both System Assigned Identities and User Assigned Identities. In a nutshell MSIs refer to the process where Azure natively recognizes the resource without the need for any type of password and or credential. It is my understanding that both of these create an Azure AD Thumbprint for recognizing the Azure resource.

Why Managed Identities

Leveraging managed identities gives the ability to grant Role Based Access Control (RBAC) roles that are either built in or custom. This helps provide a finer grain of access to specific functions within the scoped Azure resources.

Furthermore, by removing the password element decreases the risk of the credentials being compromised. Additionally, if leveraging System Assigned Identities AAD will destroy the identity after the underlying Azure resource has been deleted.

System Assigned Identity

A System Assigned Identity is an identity created and managed by Azure.

Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity, an identity is created in Azure AD. The identity is tied to the lifecycle of that service instance. When the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.

Microsoft Docs

One of the biggest things to realize with a System Assigned Identity is a 1:1 relationship in terms of one Azure resource will map to one entry in Azure Active Directory (AAD). The other is already called out above is that Azure will delete the AAD record once the resource is removed.

The System Assigned Identity is usually configured under the Managed Identity blade in the portal and is a toggle switch.

Infrastructure as Code

Those who follow me know that I am a firm believer in that nothing is “production ready” unless it is defined via Infrastructure as Code (IaC).

With System Managed Identities this is usually a simple property flag on the resource. In the case above with Stream Analytics it would be:

"identity": {
        "type": "SystemAssigned"
    }

This will tell the Azure Resource Manager (ARM) to provision a System Managed Identity for the resource.

User Assigned Identity

A User Assigned Identity is an identity created by you which can be applied to the Azure Resource:

You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more instances of an Azure service. For user-assigned managed identities, the identity is managed separately from the resources that use it.

Microsoft Docs

I typically suggest User Assigned Identity after System Assigned Identity as it will require the user to delete the identity when it is no longer being used; additionally, it could be tempting to assign everything the same identity. Which violates some of the security best practices around one identity should be doing one thing.

As stated above a User Assigned Identity is created outside of the resource creation process, as it is its own Azure resource.

In the portal it would be a similar process to assign a User Assigned Identity, assuming one has been created:

When to Use

I usually recommend using a User Assigned Identity when wanting to do something with mapping multiple resources to one identity for ease of maintenance. This could be when having a geo redundant or scaled out resource and only wanting to manage/provision one identity. This would make sense as all the instances will be running the same code and performing the same function. As such aligning them to one identity makes sense.

Another instance I ran into recently was leveraging API Management(APIM) and Key Vault integration for a custom hostname. You can check out my post for more details. The TL/DR is there are times where to create the resource access to additional services are required, Key Vault for instance. As such the identity needs to be created first, assigned the appropriate access, and then assigned to the Azure resource.

Another one I found interesting was the use case to have a User Assigned Identity run provisioning for everything in the Resource Group.

Infrastructure as Code

The User Assigned Identity will need to be created as its own Azure Resource with a name and location. Similar to:

param location string = resourceGroup().location
param userAssignIdentityName string

resource userAssignedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' = {
  name: userAssignIdentityName
  location: location
}

Then this identity will need to be assigned to the Azure Resource.

  identity:{
    type: 'SystemAssigned, UserAssigned'
    userAssignedIdentities: userAssignedIdentity
  }

User vs System Assigned Identities

When in doubt the Microsoft Documentation does provide a good breakdown comparing the two:

Conclusion

Managed Identities, both System and User Assigned, have their place within the Azure ecosystem. They can be leveraged as a best practice to grant access to Azure-to-Azure resource communication. This is done without any exchanging of credentials as the resources are already registered in AAD.

Hopefully this helps to shed some light on Managed Identities. Azure Managed Identities: User vs System Assigned