Autorotation with Managed Identity

Previously I introduced certificate rotation and why it’s important to running any cloud service. This post will describe some successful high-level concepts to enable a complete secret rotation story using Azure services.

Azure services like Storage or Maps? Invest in Azure AD Managed Identities

Storage is known for the shared secret and shared-access-signature authentication and authorization implementations. For some time now Azure has been consolidating an Azure AD authentication and role-based access control for the APIs.

This solution solves: credential management, rotation, and fine grain access control. Previously you must securely store these secrets in application configuration or secret stores and create processes for updating these secrets and deploying them safely.

Managed Identity creates an Azure AD service principal and abstracts the phrase “Get access token for Storage|Maps|etc” without the cost of certificate management or secret rotation. You can directly assign access on the Azure Storage account or at a higher-level scope such as a resource group or subscription. This works excellent for applications using service to service authentication.

It removes any need for a secret store such as Key Vault. See the picture showing that the application in the Azure VM calls Azure storage using Managed identity from the instance metadata service. There are many SDK choices to use when using the IMDS endpoint to retrieve the access token for a service. Since IMDS is REST endpoint you could even bring your own library. However, I would suggest looking into the recommended and supported SDKs from Microsoft.

MSAL and ADAL are not supported

That’s disappointing right? Good news is the Azure SDK is to be the intended SDK for the replacement of Azure services. There are existing libraries such as the Azure Service Authentication Library which also works too. ASAL library is the current recommendation for service to service authentication to Key Vault but this library can be used for other Azure services too. MSAL is the next recommendation because it is written for the strict focus of authentication with Azure AD instead of Azure Service SDK integration.

For the record

This is the production implementation for accessing Key Vaults and Storage services in Azure Maps. Currently we have been operating with it for about 1.5 years with no live site incidents related to these components.

Azure Resource Manager Template

I’ve authored an example to setup Azure RBAC using an Azure Resource Manager template. The purpose of the quick-start template is to show easy it can be to assign an application access to an Azure Maps account using a Managed Identity or other Service Principal.

The second step to using the quick-start template is to create some Azure resource with a Managed Identity. Check out the Managed Identity documentation on providing a user assigned identity from our quick-start template to a Virtual Machine Resource.

You must reference your created User Assigned Managed Identity and apply it to your resource with a template like:

{
    "apiVersion": "2018-06-01",
    "type": "Microsoft.Compute/virtualMachines",
    "name": "[variables('vmName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "userAssigned",
        "userAssignedIdentities": {
            "[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',variables(''))]": {}
        }
     }
}

One you deploy your code using one of the SDKs mentioned you can call the Azure Maps REST APIs without any need to store the shared key in a Key Vault.