Microsoft Azure — Managed Identities & Service Principals

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers managed identities & service principals with production-ready configurations, best practices, and hands-on examples.

Why Managed Identities Beat Service Principals

In Azure, authentication between services has traditionally relied on Service Principals—essentially, identity objects with a client ID and secret. The problem? Secrets get leaked. They're checked into Git, stored in config files, or rotated manually and forgotten. Managed Identities eliminate the secret management burden entirely. They're Azure's way of saying: 'Let me handle the credential lifecycle.' A Managed Identity is tied to an Azure resource (like a VM, App Service, or Function) and automatically rotates its own credentials. No secrets to store, no rotation scripts. For any workload running inside Azure, this should be your default. Service Principals are still useful for external applications or cross-tenant scenarios, but inside Azure, Managed Identities reduce attack surface and operational overhead. The trade-off? You lose the ability to use the same identity across resources—each resource gets its own identity. But that's actually a security win: least privilege per resource.

az identity create --name MyManagedIdentity --resource-group MyRG
# Output:
# {
#   "clientId": "00000000-0000-0000-0000-000000000000",
#   "principalId": "11111111-1111-1111-1111-111111111111",
#   "tenantId": "22222222-2222-2222-2222-222222222222"
# }

Setting Up a System-Assigned Managed Identity

System-assigned Managed Identities are the simplest to configure. When you enable it on an Azure resource, Azure automatically creates an identity in Azure AD tied to that resource's lifecycle. Enable it during resource creation or afterward. For an Azure VM, you can enable it via the portal, CLI, or ARM template. Once enabled, the VM can request tokens from the Azure Instance Metadata Service (IMDS) endpoint at 169.254.169.254. No code changes needed beyond using the default credential chain in SDKs. The identity is automatically deleted when the resource is deleted—no orphaned identities. This is ideal for ephemeral workloads like batch processing VMs or auto-scaling app services. The downside: you can't share the identity across resources. If you need the same identity on multiple VMs, use a user-assigned identity instead.

az vm identity assign --resource-group MyRG --name MyVM
# Verify:
az vm show --resource-group MyRG --name MyVM --query identity
# Output:
# {
#   "principalId": "33333333-3333-3333-3333-333333333333",
#   "tenantId": "22222222-2222-2222-2222-222222222222",
#   "type": "SystemAssigned"
# }

User-Assigned Managed Identities: Sharing Identity Across Resources

User-assigned Managed Identities are standalone Azure resources that you create once and assign to multiple Azure resources. This is useful when you have a fleet of VMs or multiple App Services that all need to authenticate to the same Key Vault or Storage Account. You create the identity, assign it to each resource, and grant permissions to the identity itself. The identity persists even if the resources are deleted. This decouples identity from resource lifecycle. However, you now have an extra resource to manage. User-assigned identities also support more complex scenarios like cross-region replication or using the same identity in different subscriptions (via RBAC). The trade-off: you must explicitly assign the identity to each resource, and the identity's client ID is needed in code if you're not using the default credential chain.

az identity create --name MyUserIdentity --resource-group MyRG
# Output:
# {
#   "clientId": "44444444-4444-4444-4444-444444444444",
#   "principalId": "55555555-5555-5555-5555-555555555555",
#   "tenantId": "22222222-2222-2222-2222-222222222222"
# }

# Assign to VM:
az vm identity assign --resource-group MyRG --name MyVM --identities /subscriptions/.../providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyUserIdentity

Service Principals: When and How to Use Them

Service Principals are the classic Azure AD application identities. They consist of a client ID and a client secret (or certificate). Use them when your application runs outside Azure (e.g., on-premises, another cloud) or when you need to authenticate as the application itself (e.g., for CI/CD pipelines). Service Principals are also necessary for cross-tenant scenarios where Managed Identities can't reach. The main drawback: you must manage secrets. Rotate them regularly, store them in a vault (Azure Key Vault), and never hardcode them. Use certificates instead of secrets for better security—they can be rotated without downtime. Service Principals also support OAuth 2.0 client credentials flow, which is standard for server-to-server communication. For production, always use certificates with auto-rotation via Key Vault.

az ad sp create-for-rbac --name MyServicePrincipal --role Contributor --scopes /subscriptions/MySub
# Output:
# {
#   "appId": "66666666-6666-6666-6666-666666666666",
#   "displayName": "MyServicePrincipal",
#   "password": "generated-secret",
#   "tenant": "22222222-2222-2222-2222-222222222222"
# }

Granting Permissions: RBAC for Identities

Both Managed Identities and Service Principals are Azure AD objects that can be assigned RBAC roles. The principle is the same: grant the identity the minimum permissions it needs. For Managed Identities, you assign roles to the identity's principal ID. For Service Principals, you assign roles to the app's service principal object. Use built-in roles like 'Reader', 'Contributor', or custom roles for fine-grained access. Always scope roles to the resource group or resource level, not the subscription, unless necessary. Remember: Managed Identities are security principals, so they appear in Azure AD and can be granted access to resources just like users. The key difference is that Managed Identities cannot be used to sign in interactively—they're for automated workflows only.

# Assign 'Storage Blob Data Contributor' to a managed identity
az role assignment create --assignee-object-id <principalId> --role "Storage Blob Data Contributor" --scope /subscriptions/MySub/resourceGroups/MyRG/providers/Microsoft.Storage/storageAccounts/mystorage

# For Service Principal, use --assignee with appId
az role assignment create --assignee 66666666-6666-6666-6666-666666666666 --role Reader --scope /subscriptions/MySub/resourceGroups/MyRG

Token Acquisition: How Your Code Gets Credentials

Managed Identities acquire tokens via the Azure Instance Metadata Service (IMDS) endpoint. When your code requests a token (e.g., using DefaultAzureCredential in Azure SDK), the SDK automatically calls http://169.254.169.254/metadata/identity/oauth2/token. No secrets involved. For Service Principals, the SDK uses the client ID and secret/certificate to request a token from Azure AD's OAuth endpoint. In both cases, the token is cached and refreshed automatically. The key difference: with Managed Identities, the infrastructure handles the credential; with Service Principals, your application must have access to the secret or certificate. For production, always use DefaultAzureCredential or ChainedTokenCredential to fall back from Managed Identity to Service Principal if running locally.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
# This will try Managed Identity first, then environment variables, then interactive
blob_service_client = BlobServiceClient(
    account_url="https://mystorage.blob.core.windows.net",
    credential=credential
)
# List containers
containers = blob_service_client.list_containers()
for container in containers:
    print(container.name)

Common Pitfalls and How to Avoid Them

Even with Managed Identities, things can go wrong. The most common issue is token acquisition failures due to network restrictions. IMDS endpoint (169.254.169.254) must be accessible—don't block it in NSGs or firewalls. Another pitfall: assigning roles to the wrong principal ID. For system-assigned, use the principal ID from the resource's identity block. For user-assigned, use the principal ID of the identity resource itself. Also, Managed Identities are not supported for all Azure services (e.g., some third-party SaaS). Always check documentation. Finally, beware of token expiration: tokens are valid for up to 24 hours, but SDKs handle refresh automatically. However, if you cache tokens manually, you might serve stale tokens. Let the SDK manage the lifecycle.

# Test token acquisition from a VM
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com' -H Metadata:true
# Expected output: JSON with access_token, expires_in, etc.
# If you get 400 or 403, check:
# 1. Is Managed Identity enabled on the VM?
# 2. Is the resource parameter correct?
# 3. Are there network restrictions?

Production Strategy: When to Use Which Identity Type

Your identity strategy should follow a simple rule: use Managed Identities for all Azure-internal workloads, and Service Principals only for external or cross-tenant scenarios. Within Managed Identities, prefer system-assigned for single-resource workloads (e.g., one App Service accessing one database) and user-assigned for multi-resource workloads (e.g., a VMSS writing to a common storage account). Avoid using Service Principals inside Azure unless you have no choice (e.g., legacy app that can't use IMDS). For CI/CD pipelines, use Service Principals with certificates stored in Key Vault, and rotate them automatically. For local development, use DefaultAzureCredential with Azure CLI or Visual Studio. Document your identity architecture and include it in your disaster recovery plan—if an identity is deleted, you lose access.

identity_decision:
  - scenario: "Azure resource to Azure resource"
    recommendation: "System-assigned Managed Identity"
  - scenario: "Multiple resources to same target"
    recommendation: "User-assigned Managed Identity"
  - scenario: "External app (on-prem, other cloud)"
    recommendation: "Service Principal with certificate"
  - scenario: "CI/CD pipeline"
    recommendation: "Service Principal with certificate, stored in Key Vault"
  - scenario: "Cross-tenant access"
    recommendation: "Service Principal"