Azure Managed Identities- System Identity vs User Assigned Identity

 

Managed Identities

Managed Identities are in essence 100% identical in functionality and use case than Service Principals. In fact, they are actually Service Principals.

What makes them different though, is: – They are always linked to an Azure Resource, not to an application or 3rd party connector – They are automatically created for you, including the credentials; big benefit here is that no one knows the credentials

Managed Identities exist in 2 formats: – System assigned; in this scenario, the identity is linked to a single Azure Resource, eg a Virtual Machine, a Logic App, a Storage Account, Web App, Function,… so almost anything. Next, they also “live” with the Azure Resource, which means they get deleted when the Azure Resource gets deleted. – User Assigned Managed Identity, which means that you first have to create it as a stand-alone Azure resource by itself, after which it can be linked to multiple Azure Resources. An example here could be out of an integration with Key Vault, where different Workload services belonging to the same application stack, need to read out information from Key Vault. In this case, one could create a “read KV” Managed Identity, and link it to the web app, storage account, function, logic app,… all belonging to the same application architecture.

Let’s walk through a quick demo scenario for both, using a Virtual Machine as Azure Resource:

• From the Azure Portal, select the Virtual Machine; under settings, find Identity
• Set Status as On, and save the changes

Switching to Azure Key Vault / Access Policies, we can now define this System Assigned Managed Identity having get and list permissions (or any other) for keys, secrets or certificates. For example reading out an Azure Storage Account Access key or similar.

Notice how Azure Key Vault is expecting a Service Principal object here (where in reality we are using a Managed Identity).

Similarly, let’s remove the System Assigned MI of the VM and use a User Assigned one in the next example (an Azure Resource can only be linked to one or the other, not both…):

• From the Azure Virtual Machine blade, navigate to Identity and switch the “Status” toggle button to Off.
• This will prompt for your confirmation when saving the settings

As you notice, the Managed Identity object gets immediately removed from Azure AD. Yes, security is key here…

• Wait for the deregistration of the object.

Remember that a User Assigned Managed Identity is a stand-alone Azure Resource, which needs to be created first, after which you can assign it to another Azure Resource (our VM in this scenario).

• From the Azure Portal, Create new Resource, and search for “User Assigned Managed Identity”

• click Create.
• Specify the Resource Group, Azure Region and Name for this resource.

• Confirm by clicking create and Wait for the resource creation to complete successfully.
• Once created, switch back to the Azure Virtual Machine, select Identity and select User Assigned
• Notice the Managed Identity you just created.

• Select it and add it as a Virtual Machine User Assigned object.

• Select another Azure Resource in your subscription, for example an Azure Web App, Logic App,… and once more select Identity from the settings. Below screenshot shows what it looks like for an Azure Web App Resource:

To complete the sample scenario, let’s go back to Azure Key Vault, and specify another Access Policy for this User Assigned Managed Identity:

• Select your Azure Key Vault resource, followed by selecting Access Policy from the settings.
• Specify the Key and/or Secret Permissions (for example get, list)
• Click “Select Principal” and search for the User Assigned Managed Identity you created earlier

After saving the changes, the result is that now both the Azure Virtual Machine as well as the Web App – having the User Assigned Managed Identity assigned to them – can read our keys and secrets from Azure Key Vault.

Summary

In this post, I wanted to clarify the use case, difference and similarities between Service Principals and Managed Identities. A Service Principal could be looked at as similar to a service account-alike in a more traditional on-premises application or service scenario. Managed Identities are used for “linking” a Service Principal security object to an Azure Resource like a Virtual Machine, Web App, Logic App or similar. For a 1:1 relation between both, you would use a System Assigned, where for a 1:multi relation, you would use a User Assigned Managed Identity.