Azure AD Managed Service Identity July 2018 Updates

Ever since Managed Service Identity was introduced last year, we have been thrilled about it. No more credentials stored in config files.

Since it received a bunch of updates now, we thought we'd summarize them a bit and offer our thoughts on them.

This article was also posted on the Kompozure blog here.

Recap of managed service identities

If you are not familiar with Managed Service Identity (MSI), you can check out:

The main purpose of MSI is to remove the bootstrapping problem of authentication. We could put all of our sensitive credentials in Azure Key Vault. But then we need a key to access Key Vault somewhere in the application's configuration anyway.

MSI makes the need for that key go away, and instead offers a service within your Azure service that can be used to request Azure AD access tokens. The service identity that is used is fully managed by Azure, and you do not need to worry about such as things as key rotation. You only need to:

Enable MSI on the service
- Currently supported on App Services, Functions, Virtual Machines, Scale Sets, and Data Factories (v2)
Assign permissions to the generated service identity
Use the internal service endpoint to get access tokens
Call the APIs you need with the tokens

Some services in Azure do not support Azure AD access token authentication (yet), but their access keys can be stored in Azure Key Vault and then retrieved at application startup with an access token from MSI. So, the end result is that we have 0 sensitive configuration settings in the configuration file, or even App Settings in the App Service's configuration for that matter.

A new type of managed identity

There are now two types of managed identities.

System-assigned identities are the ones that existed before and work exactly as they used to. You can enable one on e.g. an App Service instance from its configuration with a push of a button. A service principal is generated automatically in Azure AD, and the identity can be used from applications running on that service without having to worry about key management.

Identities that are system-assigned are attached to an Azure service like an App Service. That makes their lifecycle connected, so if you delete the App Service, the generated service principal in Azure AD is also deleted.

User-assigned identities work differently. They are resources in the Azure subscription that exist independently. Once you have created one, you can assign it to one or more Azure services. You will also be able to assign multiple of these identities to a service. User-assigned identities are only supported on Virtual Machines and Virtual Machine Scale Sets as of now though, but we expect them to be enabled across more services at some point.

Currently user-assigned identities can only be assigned via the Azure Resource Management API, and not via the Portal. The object model in the Resource Management API is also going to change still. So, it is best to wait for a while before trying these.

Being able to share an identity across services can make access management easier. We think they will be a great addition.

Virtual machine changes

The VM extension for Managed Identity is now deprecated. Its support will end at the end of January 2019. Requests for tokens should be addressed to the Instance Metadata Service (IMDS). This is a service available to every virtual machine in Azure.

With the extension, there were several issues. Firstly, the keys used by the managed identity were on the VM. Secondly, the VM OS had to support the extension. Neither of these is a problem with IMDS. Since it is a service separate from the VM, the keys are never on the VM itself. And because it is a REST service, it can be used from a VM running any OS.

Here is an example token request using IMDS (borrowed from the announcement):

GET 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/' HTTP/1.1
Metadata: true

It is quite similar to the extension's API, and only requires that you specify the API version and the resource that you want a token for. The IP address is always the same on any virtual machine.

A key point to note is that any code running on the VM can call this endpoint. It does not discriminate which service calls it. So a vulnerability that leads to remote code execution would be very serious. Those vulnerabilities are serious normally too of course. This is quite a lot better than with the extension though, since then the keys might be available to the attacker as well.

Overall there are only benefits to moving to use the Instance Metadata Service. The compatibility alone makes it 100% more awesome.

App Service and Functions Managed Identity GA

System-assigned identities in Azure App Service and Azure Functions are now Generally Available and are thus considered perfectly viable for production use. One thing to keep in mind is that the token endpoint cannot handle very many concurrent calls and should use caching as much as possible. The .NET library which enables use of managed identities uses caching internally. So, if you are using that, you are already covered.

Visual Studio Team Services updates

The sprint 135 update to Visual Studio Team Services enables those of you using Azure Virtual Machines as build agents an easier access management experience. You can now use managed identities to give the virtual machine access to e.g. Azure Key Vault or Azure Resource Management API and utilize those privileges in your build and release processes. No need to store secrets or create service principals manually.

Summary

Overall, great things are coming to managed identities. And with Azure AD token authentication extending to more and more Azure services (like Azure Storage which is now in preview), we are moving closer to getting rid of access keys in service authentication scenarios altogether.

We look forward to testing out user-assigned identities as soon as they are available in the Portal.