In this post, we will take a look at managed identities in general and system-assigned managed identity in particular. Managed identities can be used by your code to authenticate to Azure AD resources from Azure compute resources that support it, like virtual machines and containers.
But first, let’s look at the other option and why you should avoid it if you can: service principals.
Service Principals
If you have code that needs to authenticate to Azure AD-protected resources such as Azure Key Vault, you can always create a service principal. It’s the option that always works. It has some caveats that will be explained further in this post.
The easiest way to create a service principal is with the single Azure CLI command below:
az ad sp create-for-rbac
The command results in the following output:
{
"appId": "APP_ID",
"displayName": "azure-cli-2023-01-06-11-18-45",
"password": "PASSWORD",
"tenant": "TENANT_ID"
}
If the service principal needs access to, let’s say, Azure Key Vault, you could use the following command to grant that access:
APP_ID="appId from output above"
$SUBSCRIPTION_ID="your subscription id"
$RESOURCE_GROUP="your resource group"
$KEYVAULT_NAME="short name of your key vault"
az role assignment create --assignee $APP_ID \
--role "Key Vault Secrets User" \
--scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEYVAULT_NAME"
The next step is to configure your application to use the service principal and its secret to obtain an Azure AD token (or credential) that can be passed to Azure Key Vault to retrieve secrets or keys. That means you need to find a secure way to store the service principal secret with your application, which is something you want to avoid.
In a Python app, you can use the ClientSecretCredential class and pass your Azure tenant id, the service principal appId (or client Id) and the secret. You can then use the secret with a SecretClient like in the snippet below.
# Create a credential object
credential = ClientSecretCredential(tenant_id, client_id, client_secret)
# Create a SecretClient using the credential
client = SecretClient(vault_url=VAULT_URL, credential=credential)
Other languages and frameworks have similar libraries to reach the same result. For instance JavaScript and C#.
This is quite easy to do but again, where do you store the service principal’s secret securely?
The command az ad sp create-for-rbac also creates an App Registration (and Enterprise application) in Azure AD:
The secret (or password) for our service principal is partly displayed above. As you can see, it expires a year from now (blog post written on January 6th, 2023). You will need to update the secret and your application when that time comes, preferably before that. We all know what expiring secrets and certificates give us: an app that’s not working because we forgot to update the secret or certificate!
💡 Note that one year is the default. You can set the number of years with the --years parameter in az ad sp create-for-rbac.
💡 There will always be cases where managed identities are not supported such as connecting 3rd party systems to Azure. However, it should be clear that whenever managed identity is supported, use it to provide your app with the credentials it needs.
In what follows, we will explain managed identities in general, and system-assigned managed identity in particular. Another blog post will discuss user-assigned managed identity.
Managed Identities Explained
Azure Managed Identities allow you to authenticate to Azure resources without the need to store credentials or secrets in your code or configuration files.
There are two types of Managed Identities:
- system-assigned
- user-assigned
System-assigned Managed Identities are tied to a specific Azure resource, such as a virtual machine or Azure Container App. When you enable a system-assigned identity for a resource, Azure creates a corresponding identity in the Azure Active Directory (AD) for that resource, similar to what you have seen above. This identity can be used to authenticate to any service that supports Azure AD authentication. The lifecycle of a system-assigned identity is tied to the lifecycle of the Azure resource. When the resource is deleted, the corresponding identity is also deleted. Via a special token endpoint, your code can request an access token for the resource it wants to access.
User-assigned Managed Identities, on the other hand, are standalone identities that can be associated with one or more Azure resources. This allows you to use the same identity across multiple resources and manage the identity’s lifecycle independently from the resources it is associated with. In your code, you can request an access token via the same special token endpoint. You will have to specify the appId (client Id) of the user-managed identity when you request the token because multiple identities could be assigned to your Azure resource.
In summary, system-assigned Managed Identities are tied to a specific resource and are deleted when the resource is deleted, while user-assigned Managed Identities are standalone identities that can be associated with multiple resources and have a separate lifecycle.
System-assigned managed identity
Virtual machines support system and user-assigned managed identity and make it easy to demonstrate some of the internals.
Let’s create a Linux virtual machine and enable a system-assigned managed identity. You will need an Azure subscription and be logged on with the Azure CLI. I use a Linux virtual machine here to demonstrate how it works with bash. Remember that this also works on Windows VMs and many other Azure resources such as App Services, Container Apps, and more.
Run the code below. Adapt the variables for your environment.
RG="rg-mi"
LOCATION="westeurope"
PASSWORD="oE2@pl9hwmtM"
az group create --name $RG --location $LOCATION
az vm create \
--name vm-demo \
--resource-group $RG \
--image UbuntuLTS \
--size Standard_B1s \
--admin-username azureuser \
--admin-password $PASSWORD \
--assign-identity
After the creation of the resource group and virtual machine, the portal shows the system assigned managed identity in the virtual machine’s Identity section:
We can now run some code on the virtual machine to obtain an Azure AD token for this identity that allows access to a Key Vault. Key Vault is just an example here.
We will first need to create a Key Vault and a secret. After that we will grant the managed identity access to this Key Vault. Run these commands on your own machine, not the virtual machine you just created:
# generate a somewhat random name for the key vault
KVNAME=kvdemo$RANDOM
# create with vault access policy which grants creator full access
az keyvault create --name $KVNAME --resource-group $RG
# with full access, current user can create a secret
az keyvault secret set --vault-name $KVNAME --name mysecret --value "TOPSECRET"
# show the secret; should reveal TOPSECRET
az keyvault secret show --vault-name $KVNAME --name mysecret
# switch the Key Vault to AAD authentication
az keyvault update --name $KVNAME --enable-rbac-authorization
Now we can grant the system assigned managed identity access to Key Vault via Azure RBAC. Let’s look at the identity with the command below:
az vm identity show --resource-group $RG --name vm-demoThis returns the information below. Note that principalId was also visible in the portal as Object (principal) ID. Yes, not confusing at all… 🤷♂️
{
"principalId": "YOUR_PRINCIPAL_ID",
"tenantId": "YOUR_TENANT_ID",
"type": "SystemAssigned",
"userAssignedIdentities": null
}Now assign the Key Vault Secrets User role to this identity:
PRI_ID="principal ID above"
SUB_ID="Azure subscription ID"
# below, scope is the Azure Id of the Key Vault
az role assignment create --assignee $PRI_ID \
--role "Key Vault Secrets User" \
--scope "/subscriptions/$SUB_ID/resourceGroups/$RG/providers/Micr
osoft.KeyVault/vaults/$KVNAME"
If you check the Key Vault in the portal, in IAM, you should see:
Now we can run some code on the VM to obtain an Azure AD token to read the secret from Key Vault. SSH into the virtual machine using its public IP address with ssh azureuser@IPADDRESS. Next, use the commands below:
# install jq on the vm for better formatting; you will be asked for your password sudo snap install jq curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net' -H Metadata:true | jq
It might look weird but by sending the curl request to that special IP address on the VM, you actually request an access token to access Key Vault resources (in this case, it could also be another type of resource). There’s more to know about this special IP address and the other services it provides. Check Microsoft Learn for more information.
The result of the curl command is JSON below (nicely formatted with jq):
{
"access_token": "ACCESS_TOKEN",
"client_id": "CLIENT_ID",
"expires_in": "86038",
"expires_on": "1673095093",
"ext_expires_in": "86399",
"not_before": "1673008393",
"resource": "https://vault.azure.net",
"token_type": "Bearer"
}
Note that you did not need any secret to obtain the token. Great!
Now run the following code but first replace <YOUR VAULT NAME> with the short name of your Key Vault:
# build full URL to your Key Vault VAULTURL="https://<YOUR VAULT NAME>.vault.azure.net" ACCESS_TOKEN=$(curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net' -H Metadata:true | jq -r .access_token) curl -s "$VAULTURL/secrets/mysecret?api-version=2016-10-01" -H "Authorization: Bearer $ACCESS_TOKEN" | jq -r .value
First, we set the vault URL to the full URL including https://. Next, we retrieve the full JSON token response but use jq to only grab the access token. The -r option strips the " from the response. Next, we use the Azure Key Vault REST API to read the secret with the access token for authorization. The result should be TOPSECRET! 😀
Instead of this raw curl code, which is great for understanding how it works under the hood, you can use Microsoft’s identity libraries for many popular languages. For example in Python:
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
# Authenticate using a system-assigned managed identity
credential = DefaultAzureCredential()
# Create a SecretClient using the credential and the key vault URL
secret_client = SecretClient(vault_url="https://YOURKVNAME.vault.azure.net", credential=credential)
# Retrieve the secret
secret = secret_client.get_secret("mysecret")
# Print the value of the secret
print(secret.value)
If you are somewhat used to Python, you know you will need to install azure-identity and azure-keyvault-secrets with pip. The DefaultAzureCredential class used in the code automatically works with system managed identity in virtual machines but also other compute such as Azure Container Apps. The capabilities of this class are well explained in the docs: https://learn.microsoft.com/en-us/python/api/overview/azure/identity-readme?view=azure-python. The identity libraries for other languages work similarly.
What about Azure Arc-enabled servers?
Azure Arc-enabled servers also have a managed identity. It is used to update the properties of the Azure Arc resource in the portal. You can grant this identity access to other Azure resources such as Key Vault and then grab the token in a similar way. Similar but not quite identical. The code with curl looks like this (from the docs):
ChallengeTokenPath=$(curl -s -D - -H Metadata:true "http://127.0.0.1:40342/metadata/identity/oauth2/token?api-version=2019-11-01&resource=https%3A%2F%2Fvault.azure.net" | grep Www-Authenticate | cut -d "=" -f 2 | tr -d "[:cntrl:]")
ChallengeToken=$(cat $ChallengeTokenPath)
if [ $? -ne 0 ]; then
echo "Could not retrieve challenge token, double check that this command is run with root privileges."
else
curl -s -H Metadata:true -H "Authorization: Basic $ChallengeToken" "http://127.0.0.1:40342/metadata/identity/oauth2/token?api-version=2019-11-01&resource=https%3A%2F%2Fvault.azure.net"
fi
On an Azure Arc-enabled machine that runs on-premises or in other clouds, the special IP address 169.254.169.254 is not available. Instead, the token request is sent to http://localhost:40342. The call is designed to fail and respond with a Www-Authenticate header that contains the path to a file on the machine (created dynamically). Only specific users and groups on the machine are allowed to read the contents of that file. This step was added for extra security so that not every process can read the contents of this file.
The second command retrieves the contents of the file and uses it for basic authentication purposes in the second curl request. It’s the second curl request that will return the access token.
Note that this works for both Linux and Windows Azure Arc-enabled systems. It is further explained here: https://learn.microsoft.com/en-us/azure/azure-arc/servers/managed-identity-authentication.
In contrast with managed identity on Azure compute, I am not aware of support for Azure Arc in the Microsoft identity libraries. To obtain a token with Python, check the following gist with some sample code: https://gist.github.com/gbaeke/343b14305e468aa433fe90441da0cabd.
The great thing about this is that managed identity can work on servers not in Azure as long if you enable Azure Arc on them! 🎉
Conclusion
In this post, we looked at what managed identities are and zoomed in on system-assigned managed identity. Azure Managed Identities are a secure and convenient way to authenticate to Azure resources without having to store credentials in code or configuration files. Whenever you can, use managed identity instead of service principals. And as you have seen, it even works with compute that’s not in Azure, such as Azure Arc-enabled servers.
Stay tuned for the next post about user-assigned managed identity.
Microsoft has recently published updated Office 365 Service Descriptions at 
baeke.info 