Managed Service Identity for Azure Resources

A Managed Service Identity (MSI) is a feature that is in public preview where it gives an Azure Service an automatically managed identity in the Azure Active Directory that can be used to authenticate to any Azure Service that supports Azure AD Authentication.

In most scenarios, you need to authenticate in to cloud services in order to use them and its not a good practice to keep the secrets used for this authentication in your source code or in your local development machines. Keeping these secrets secure is very important and a service like Azure Key Vault makes this much easier. But to access Azure Key Vault, you also need to authenticate. And Manages Service Identities comes in handy to solve this problem.

There are two types of Managed Service Identities (MSI) System Assigned and User Assigned. We’ll look at what they are now.

System Assigned Identity

A System Assigned Identity is directly enabled on the Azure Service Instance. This creates an identity in the Azure AD Tenant trusted by the Subscription. Once this is done, the credentials get provisioned on to the service instance and the lifecycle of the Identity is automatically managed by Azure. Its tied to the service instance that the MSI is enabled on. That means when the service instance is deleted, Azure will automatically clean up the credentials and the identity in the Azure AD.

User Assigned Identity

This is a standalone resource created in the Azure AD Tenant trusted by the subscription. Once created this identity can be assigned to one or mode Azure Service Instances and the lifecycle of this identity is not tied to any specific Service Instance, it has to be managed separately.

The Managed Service Identities are created free of charge. They are part of the Azure AD. Also there are many services that support MSIs including Azure App Service, Virtual Machines etc. For a full list of supported services use the following documentation link for more details.

How This Works

In this example scenario, we’ll look at how a System Assigned Managed Service Identity is used to access the Azure Key Vault from code running within an Azure Virtual Machine.

• When Azure Resource Manager gets a request to enable Managed Service Identity (in this case a System Assigned Identity) on the Virtual Machine we are working on, Azure Resource Manager goes ahead and creates a Service Principle in the Azure AD. This represents the Identity of the Virtual Machine.
• Then Azure Resource Manager Provisions the Managed Service Identity Extension on the VM and adds the Client ID and the Certificate for the Service Principle and also updates the Azure Instance Metadata Service identity endpoint with the client id and the secret.

Note: The VM extension for Manages Service Identity will be deprecated soon. So, going forward the Azure Instance Metadata Service will be used instead.

• Next, since now the Service Principle for the VM is in the Azure AD we can go ahead and add that identity in to the resources we need to access from our code. In our case we would go to the Azure Key Vault instance we created and add an Access Policy using the service principle that was created earlier.
• Then the application code can request the access token from Azure AD by using either the VM extension or the Instance Metadata Service (IMDS). These 2 are only accessible from with in the VM. The Azure AD returns the JWT Access Token that is required to access the Key Vault
• Then your application code can use the access token when communicating with the Azure Key Vault instance since its supporting Azure AD authentication to retrieve the keys and secrets the application wants.