System DesignMedium
What is Azure Managed Identity and why use it?
Managed Identity (MI) lets an Azure resource (App Service, Container App, VM, Functions) authenticate to other Azure resources WITHOUT credentials in code or config.
The old way — connection strings with passwords:
var connStr = "Server=sql.example.com;User Id=admin;Password=SuperSecret;";
// Password lives in env vars / Key Vault / accidentally in source
Risks: secrets in configuration, password rotation pain, ex-employees with cached creds.
With Managed Identity — code carries zero credentials:
// SQL connection using AAD identity
var conn = new SqlConnection {
ConnectionString = "Server=sql.example.com;Database=app;",
AccessToken = await new DefaultAzureCredential().GetTokenAsync(
new TokenRequestContext(new[] { "https://database.windows.net/.default" })
).Token
};
DefaultAzureCredential auto-detects:
- Inside Azure: uses the resource's Managed Identity
- Locally: falls back to your
az logincredentials - CI: env vars (
AZURE_CLIENT_IDetc.)
Two flavours:
- System-assigned — created with the resource, deleted with it (1:1)
- User-assigned — created independently, attachable to multiple resources
Common targets:
- Azure SQL — grant the MI a DB user, query as that identity
- Azure Storage — Blob Data Reader role at the storage account
- Key Vault — Secret User role for app secrets
- Service Bus, Cosmos DB, Event Hubs — all support MI
Why use it:
- No secrets to leak, rotate, or exfiltrate
- Audit trail in Azure AD logs (who/what/when accessed what)
- Same code works locally (via
az login) and in production (via MI)
Practical setup (Bicep):
resource appService 'Microsoft.Web/sites@2023-01-01' = {
identity: { type: 'SystemAssigned' }
}
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
scope: keyVault
properties: {
principalId: appService.identity.principalId
roleDefinitionId: keyVaultSecretsUserRoleId
}
}
Within minutes the app can fetch secrets from Key Vault with zero secrets baked in.