Managed Identities in Code

Managed Identities (formerly known as Managed Service Identities, MSI) provide Azure services with an automatically managed identity in Azure Active Directory. This identity can be used to authenticate to any service that supports Azure AD authentication, such as Key Vault, Storage, SQL Database, and more. The primary benefit is eliminating the need for developers to manage credentials—no connection strings, no client secrets, no certificates stored in app settings or code. This reduces security risks and operational overhead.

There are two types: System-assigned and User-assigned.

System-assigned Managed Identity is enabled directly on an Azure resource (e.g., a Virtual Machine, App Service, or Function App). When enabled, Azure creates a service principal of the same name as the resource in the Azure AD tenant trusted by the subscription. The lifecycle of this identity is tied to the resource: if the resource is deleted, the identity is automatically removed.

User-assigned Managed Identity is created as a standalone Azure resource. It can be assigned to one or more Azure resources. Its lifecycle is independent of any resource; deleting a resource does not delete the identity. This allows reuse across multiple resources.

When a resource with a Managed Identity requests a token, the Azure Instance Metadata Service (IMDS) endpoint at 169.254.169.254 is used. The process is as follows:

Enable system-assigned identity on a VM using Azure CLI:

az vm identity assign -g MyResourceGroup -n MyVm

Enable system-assigned identity on an App Service:

az webapp identity assign -g MyResourceGroup -n MyApp

Create a user-assigned identity:

az identity create -g MyResourceGroup -n MyUserIdentity

Assign user-assigned identity to a VM:

az vm identity assign -g MyResourceGroup -n MyVm --identities /subscriptions/.../providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyUserIdentity

Get the client ID of a user-assigned identity:

az identity show -g MyResourceGroup -n MyUserIdentity --query clientId

Test token acquisition from a VM (via curl):

curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -H Metadata:true

Grant the identity access to Key Vault:

az keyvault set-policy --name MyVault --object-id <principal-id> --secret-permissions get list

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

public class KeyVaultExample
{
    public async Task<string> GetSecretAsync(string keyVaultUrl, string secretName)
    {
        // Use DefaultAzureCredential which includes ManagedIdentityCredential
        var client = new SecretClient(new Uri(keyVaultUrl), new DefaultAzureCredential());
        KeyVaultSecret secret = await client.GetSecretAsync(secretName);
        return secret.Value;
    }
}

DefaultAzureCredential tries multiple authentication sources in order: Environment variables, Managed Identity, Visual Studio, Azure CLI, etc. For production, you can use ManagedIdentityCredential directly.

A financial services company uses Azure Functions to process transactions. The functions need to read secrets (e.g., database connection strings) from Key Vault. Previously, developers stored Key Vault URIs in app settings, but the connection strings themselves were in Key Vault. To authenticate, they used service principals with client secrets stored in app settings. This became a security risk because the client secret was effectively a credential in the code. With Managed Identities, they enabled system-assigned identity on each Function App, granted the 'Key Vault Secrets User' role to each identity, and updated the code to use DefaultAzureCredential. Now, no credentials are stored anywhere. The solution scales to hundreds of functions, each with its own identity. A common misconfiguration is forgetting to grant the identity permissions at the Key Vault scope, leading to 403 Forbidden errors. Also, if the Function App is deleted and recreated, a new identity is created, and permissions must be reassigned.

A healthcare organization runs a batch processing application on Azure VMs that reads medical images from Blob Storage. The application needs to authenticate to Storage. Previously, they used storage account keys stored in environment variables, which were exposed if the VM was compromised. With Managed Identities, they enabled system-assigned identity on each VM, assigned the 'Storage Blob Data Reader' role to the identity at the storage account scope, and used the Azure Identity SDK in the application. The performance impact is negligible because token acquisition is fast (typically <100ms). However, if the VM is cloned (e.g., from a captured image), the new VM will have a different identity, and permissions must be set separately. A common issue is that the IMDS endpoint is only accessible from within the VM; you cannot test token acquisition from outside.

A large e-commerce platform uses multiple Azure services (App Service, Functions, Container Instances) that all need to access the same Key Vault. Instead of enabling system-assigned identity on each resource and granting permissions individually, they create a single user-assigned identity and assign it to all resources. This simplifies permission management: only one RBAC assignment is needed. However, the downside is that the identity has broad access; if one resource is compromised, the attacker can access Key Vault on behalf of any resource using that identity. Therefore, user-assigned identities should be used carefully, with the principle of least privilege. The maximum of 20 identities per resource is rarely an issue, but the 1000 per subscription limit can be reached in large enterprises.