Managed Identities

Managed identities eliminate the need to store credentials in code, configuration files, or key vaults when Azure resources need to authenticate to other Azure services. They provide an automatically managed identity in Entra ID that your code can use to obtain access tokens without handling secrets.

---

The Problem Managed Identities Solve

Consider a web application hosted in Azure App Service that needs to read data from Azure SQL Database. Without managed identities, you would need to:

1. Create a service account or application registration
2. Generate a client secret or certificate
3. Store the secret in your application configuration or a key vault
4. Rotate the secret before it expires
5. Handle secret leaks if the configuration is compromised

This creates operational overhead and security risk. Managed identities remove all of these steps.

---

How Managed Identities Work

1. You enable a managed identity on an Azure resource (e.g., a VM, App Service, or Function App)
2. Azure creates a service principal in Entra ID automatically
3. Azure manages the credentials (certificates) behind the scenes — you never see or handle them
4. Your code requests a token from the Azure Instance Metadata Service (IMDS) endpoint
5. IMDS returns an access token that your code uses to authenticate to target services

Azure Resource (e.g., App Service)
  |
  |-- Requests token from IMDS (http://169.254.169.254/metadata/identity/oauth2/token)
  |
  v
Azure Instance Metadata Service
  |
  |-- Authenticates using the managed identity's certificate
  |
  v
Microsoft Entra ID
  |
  |-- Returns access token
  |
  v
Target Service (e.g., Azure SQL, Key Vault, Storage)

---

Types of Managed Identities

System-Assigned Managed Identity

• Created as part of an Azure resource (e.g., a specific VM or App Service)
• Lifecycle is tied to the resource — when the resource is deleted, the identity is deleted
• One identity per resource
• Best for scenarios where the identity should not outlive the resource

User-Assigned Managed Identity

• Created as a standalone Azure resource in a resource group
• Can be assigned to multiple resources (e.g., several VMs sharing the same identity)
• Independent lifecycle — deleting a resource does not delete the identity
• Best for scenarios where multiple resources need the same permissions, or the identity should persist across resource redeployments

Comparison

Aspect	System-Assigned	User-Assigned
Creation	Enabled on a resource	Created as a standalone resource
Lifecycle	Tied to the resource	Independent
Sharing	One resource only	Multiple resources
Use case	Single-resource workloads	Shared workloads, redeployment scenarios

---

Enabling Managed Identities

System-Assigned (Azure CLI)

# Enable on an App Service
az webapp identity assign --name myWebApp --resource-group myResourceGroup