What is Managed Service Identity for Azure resources?

Managed Service Identity 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 the Supplemental Terms of Use for Microsoft Azure Previews.

A common challenge when building cloud applications is how to manage the credentials in your code for authenticating to cloud services. Keeping the credentials secure is an important task. Ideally, the credentials never appear on developer workstations and aren't checked into source control. Azure Key Vault provides a way to securely store credentials, secrets, and other keys, but your code has to authenticate to Key Vault to retrieve them.

The Managed Service Identity feature in Azure Active Directory (Azure AD) solves this problem. The feature provides Azure services with an automatically managed identity in Azure AD. You can use the identity to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in your code.

The Managed Service Identity feature is free with Azure AD for Azure subscriptions. There's no additional cost.

How does the feature work?

There are two types of managed identities:

  • A system assigned identity is enabled directly on an Azure service instance. When the identity is enabled, Azure creates an identity for the instance in the Azure AD tenant that's trusted by the subscription of the instance. After the identity is created, the credentials are provisioned onto the instance. The lifecycle of a system assigned identity is directly tied to the Azure service instance that it's enabled on. If the instance is deleted, Azure automatically cleans up the credentials and the identity in Azure AD.
  • A user assigned identity is created as a standalone Azure resource. Through a create process, Azure creates an identity in the Azure AD tenant that's trusted by the subscription in use. After the identity is created, the identity can be assigned to one or more Azure service instances. The lifecycle of a user assigned identity is managed separately from the lifecycle of the Azure service instances to which it's assigned.

Your code can use a managed service identity to request access tokens for services that support Azure AD authentication. Azure takes care of rolling the credentials that are used by the service instance.

The following diagram shows how managed service identities work with Azure virtual machines (VMs):

Managed service identities and Azure VMs

How a system assigned identity works with an Azure VM

  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 for the identity of the VM. The service principal is created in the Azure AD tenant that's trusted by the subscription.
  3. Azure Resource Manager configures the identity on the VM:
    1. Updates the Azure Instance Metadata Service identity endpoint with the service principal client ID and certificate.
    2. Provisions the VM extension, and adds the service principal client ID and certificate. (This step is planned for deprecation.)
  4. After the VM has an identity, use the service principal information to grant the VM access to Azure resources. To call Azure Resource Manager, use role-based access control (RBAC) in Azure AD to assign the appropriate role to the VM service principal. To call Key Vault, grant your code access to the specific secret or key in Key Vault.
  5. Your code that's running on the VM can request a token from two endpoints that are accessible only from within the VM:

    • Azure Instance Metadata Service identity endpoint (recommended): http://169.254.169.254/metadata/identity/oauth2/token
      • The resource parameter specifies the service to which the token is sent. To authenticate to Azure Resource Manager, use resource=https://management.azure.com/.
      • API version parameter specifies the IMDS version, use api-version=2018-02-01 or greater.
    • VM extension endpoint (planned for deprecation): http://localhost:50342/oauth2/token
      • The resource parameter specifies the service to which the token is sent. To authenticate to Azure Resource Manager, use resource=https://management.azure.com/.
  6. A call is made to Azure AD to request an access token (as specified in step 5) by 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.

How a user assigned identity works with an Azure VM

  1. Azure Resource Manager receives a request to create a user assigned identity.
  2. Azure Resource Manager creates a service principal in Azure AD for the user assigned identity. The service principal is created in the Azure AD tenant that's trusted by the subscription.
  3. Azure Resource Manager receives a request to configure the user assigned identity on a VM:
    1. Updates the Azure Instance Metadata Service identity endpoint with the user assigned identity service principal client ID and certificate.
    2. Provisions the VM extension, and adds the user assigned identity service principal client ID and certificate. (This step is planned for deprecation.)
  4. After the user assigned identity is created, use the service principal information to grant the identity access to Azure resources. To call Azure Resource Manager, use RBAC in Azure AD to assign the appropriate role to the service principal of the user assigned identity. To call Key Vault, grant your code access to the specific secret or key in Key Vault.

    Note

    You can also do this step before step 3.

  5. Your code that's running on the VM can request a token from two endpoints that are accessible only from within the VM:

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

      • The resource parameter specifies the service to which the token is sent. To authenticate to Azure Resource Manager, use resource=https://management.azure.com/.
      • The client ID parameter specifies the identity for which the token is requested. This value is required for disambiguation when more than one user assigned identity is on a single VM.
      • The API version parameter specifies the Azure Instance Metadata Service version. Use api-version=2018-02-01 or higher.
    • VM extension endpoint (planned for deprecation): http://localhost:50342/oauth2/token

      • The resource parameter specifies the service to which the token is sent. To authenticate to Azure Resource Manager, use resource=https://management.azure.com/.
      • The client ID parameter specifies the identity for which the token is requested. This value is required for disambiguation when more than one user assigned identity is on a single VM.
  6. A call is made to Azure AD to request an access token (as specified in step 5) by 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.

How can I use managed service identities?

To learn how to use managed service identities to access different Azure resources, try these tutorials.

Learn how to use a managed service identity with a Windows VM:

Learn how to use a managed service identity with a Linux VM:

Learn how to use a managed service identity with other Azure services:

What Azure services support the feature?

Managed service identities can be used to authenticate to services that support Azure AD authentication. For a list of Azure services that support the Managed Service Identity feature, see Services that support Managed Service Identity.

Next steps

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