What is Managed Service Identity (MSI) for Azure resources?

Managed Service Identity (MSI) is a public preview feature of Azure Active Directory. Make sure you review the known issues before you begin. For more information about previews, see Supplemental Terms of Use for Microsoft Azure Previews.

A common challenge when building cloud applications is how to manage the credentials that need to be in your code for authenticating to cloud services. Keeping these credentials secure is an important task. Ideally, they never appear on developer workstations or get checked into source control. Azure Key Vault provides a way to securely store credentials and other keys and secrets, but your code needs to authenticate to Key Vault to retrieve them. Managed Service Identity (MSI) makes solving this problem simpler by giving Azure services an automatically managed identity in Azure Active Directory (Azure AD). You can use this identity to authenticate to any service that supports Azure AD authentication, including Key Vault, without having any credentials in your code.

How does it work?

There are two types of Managed Service Identities: System Assigned and User Assigned.

  • A System Assigned Identity is enabled directly on an Azure service instance. When enabled, Azure creates an identity for the service instance in the Azure AD tenant trusted by the subscription of the service instance. Once the identity is created, its credentials get provisioned onto the service instance. The life cycle of a system assigned identity is directly tied to the Azure service instance it is enabled on. If the service instance is deleted, Azure automatically cleans up the credentials and the identity in Azure AD.
  • A User Assigned Identity (public preview) is created as a standalone Azure resource. Through a create process, Azure creates an identity in the Azure AD tenant trusted by the subscription being used. After the identity is created, it can be assigned to one or more Azure service instances. The life cycle of a user assigned identity is managed separately from the life cycle of the Azure service instances it is assigned to.

As a result, your code can use either a system assigned or user assigned identity, to request access tokens for services that support Azure AD authentication. All while Azure takes care of rolling the credentials used by the service instance.

Here's an example of how System Assigned Identities work with Azure Virtual Machines:

Virtual Machine MSI example

  1. Azure Resource Manager receives a request to enable the system assigned identity on a VM.
  2. Azure Resource Manager creates a Service Principal in Azure AD to represent the identity of the VM. The Service Principal is created in the Azure AD tenant that is trusted by this subscription.
  3. Azure Resource Manager configures the identity on the VM: a. Updates the Azure Instance Metadata Service identity endpoint with the Service Principal client ID and certificate. b. Provisions the MSI VM extension and adds the Service Principal client ID and certificate. (to be deprecated)
  4. Now that the VM has an identity, we use its Service Principal information to grant the VM access to Azure resources. For example, if your code needs to call Azure Resource Manager, then you would assign the VM’s Service Principal the appropriate role using Role-Based Access Control (RBAC) in Azure AD. If your code needs to call Key Vault, then you would grant your code access to the specific secret or key in Key Vault.
  5. Your code running on the VM can request a token from two endpoints that are only accessible from within the VM:

    a. Azure Instance Metadata Service (IMDS) identity endpoint: http://169.254.169.254/metadata/identity/oauth2/token (recommended)

    • Resource parameter specifies the service to which the token is sent. For example, if you want your code to authenticate to Azure Resource Manager, you would use resource=https://management.azure.com/.
    • API version parameter specifies the IMDS version, use api-version=2018-02-01 or greater.

      b. MSI VM extension endpoint: http://localhost:50342/oauth2/token (to be deprecated)

    • Resource parameter specifies the service to which the token is sent. For example, if you want your code to authenticate to Azure Resource Manager, you would use resource=https://management.azure.com/.
  6. Call is made to Azure AD requesting an access token as specified in step #5, using the client ID and certificate configured in step #3. Azure AD returns a JSON Web Token (JWT) access token.

  7. Your code sends the access token on a call to a service that supports Azure AD authentication.

Using the same diagram, here's an example of how a user-assigned MSI works with Azure Virtual Machines.

  1. Azure Resource Manager receives a request to create a user assigned identity.
  2. Azure Resource Manager creates a Service Principal in Azure AD to represent the user assigned identity. The Service Principal is created in the Azure AD tenant that is trusted by this subscription.
  3. Azure Resource Manager receives a request to configure the user assigned identity on a VM: a. Updates the Azure Instance Metadata Service identity endpoint with the user assigned identity Service Principal client ID and certificate. b. Provisioning the MSI VM extension and adds the user assigned identity Service Principal client ID and certificate (to be deprecated).
  4. Now that the user assigned identity has been created, we use its Service Principal information to grant it access to Azure resources. For example, if your code needs to call Azure Resource Manager, then you would assign the Service Principal of the user assigned identity, the appropriate role using Role-Based Access Control (RBAC) in Azure AD. If your code needs to call Key Vault, then you would grant your code access to the specific secret or key in Key Vault. Note: This step can be performed before step #3 as well.
  5. Your code running on the VM can request a token from two endpoints that are only accessible from within the VM:

    a. Azure Instance Metadata Service (IMDS) identity endpoint: http://169.254.169.254/metadata/identity/oauth2/token (recommended)

    • Resource parameter specifies the service to which the token is sent. For example, if you want your code to authenticate to Azure Resource Manager, you would use resource=https://management.azure.com/.
    • Client ID parameter specifies the identity for which the token is requested. This is required to disambiguate when more than one user assigned identities are on a single VM.
    • API version parameter specifies the IMDS version, use api-version=2018-02-01 or greater.

      b. MSI VM extension endpoint: http://localhost:50342/oauth2/token (to be deprecated)

    • Resource parameter specifies the service to which the token is sent. For example, if you want your code to authenticate to Azure Resource Manager, you would use resource=https://management.azure.com/.
    • Client ID parameter specifies the identity for which the token is requested. This is required to disambiguate when more than one user assigned identities are on a single VM.
  6. Call is made to Azure AD requesting an access token as specified in step #5, using the client ID and certificate configured in step #3. Azure AD returns a JSON Web Token (JWT) access token.
  7. Your code sends the access token on a call to a service that supports Azure AD authentication.

Try Managed Service Identity

Try a Managed Service Identity tutorial to learn end-to-end scenarios for accessing different Azure resources:

From MSI-enabled resource Learn how to
Azure VM (Windows) Access Azure Data Lake Store with a Windows VM Managed Service Identity
Access Azure Resource Manager with a Windows VM Managed Service Identity
Access Azure SQL with a Windows VM Managed Service Identity
Access Azure Storage via access key with a Windows VM Managed Service Identity
Access Azure Storage via SAS with a Windows VM Managed Service Identity
Access a non-Azure AD resource with a Windows VM Managed Service Identity and Azure Key Vault
Azure VM (Linux) Access Azure Data Lake Store with a Linux VM Managed Service Identity
Access Azure Resource Manager with a Linux VM Managed Service Identity
Access Azure Storage via access key with a Linux VM Managed Service Identity
Access Azure Storage via SAS with a Linux VM Managed Service Identity
Access a non-Azure AD resource with a Linux VM Managed Service Identity and Azure Key Vault
Azure App Service Use Managed Service Identity with Azure App Service or Azure Functions
Azure Functions Use Managed Service Identity with Azure App Service or Azure Functions
Azure Service Bus Use Managed Service Identity with Azure Service Bus
Azure Event Hubs Use Managed Service Identity with Azure Event Hubs

Which Azure services support Managed Service Identity?

Managed identities can be used to authenticate to services that support Azure AD authentication. For a list of Azure services that support Managed Service Identity refer to the following article:

How much does Managed Service Identity cost?

Managed Service Identity comes with Azure Active Directory Free, which is the default for Azure subscriptions. There is no additional cost for Managed Service Identity.

Support and feedback

We would love to hear from you!

Next steps

Get started with Azure Managed Service Identity with the following quickstarts: