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"

Managed Identities for Specific Azure Services

Managed Identities are supported on most Azure compute services, but the implementation details vary. For App Service and Azure Functions, enable identity in the portal or CLI and use the az webapp identity assign command; the SDK's DefaultAzureCredential automatically picks it up. For AKS, use OIDC issuer and workload identity federation: associate a user-assigned managed identity with a Kubernetes service account. For Azure Container Apps, enable identity at the revision level and reference it in the container's environment. For Logic Apps, use managed identity connectors to authenticate to Office 365, SQL Server, or Key Vault without secrets. For API Management, use managed identities to access backend services. For Azure Data Factory, use managed identity for authentication to linked services. For each service, the identity's principal ID must be granted RBAC on the target resource. Not all Azure services support managed identities — check the 'Services that support managed identities' documentation before designing your architecture.

# Enable system-assigned identity on App Service
az webapp identity assign --name myapp --resource-group myRG

# Grant access to Key Vault
az role assignment create \
  --assignee $(az webapp identity show --name myapp --resource-group myRG --query principalId -o tsv) \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/.../resourceGroups/myRG/providers/Microsoft.KeyVault/vaults/myVault

Workload Identity Federation: Managed Identity as FIC

Workload Identity Federation enables using a managed identity as a Federated Identity Credential (FIC) on an Entra ID application. This bridges the gap when you need an Entra ID application identity but want to avoid managing secrets. The workflow: create a user-assigned managed identity, configure it as a federated identity credential on an existing Entra ID app registration with a subject identifier (e.g., the managed identity's principal ID), then your workload assumes the managed identity to get tokens that map to the Entra ID app. This is useful for scenarios like GitHub Actions deploying to Azure (where GitHub Actions needs an Entra ID app for OIDC) or when a third-party SaaS requires an Entra ID app for authentication. Up to 20 FICs per application are supported. This feature eliminates the need for client secrets entirely — even for non-Azure workloads that require an Entra ID application identity.

# Create user-assigned managed identity
az identity create --name github-actions-mi --resource-group myRG

# Get managed identity principal ID
MI_PRINCIPAL_ID=$(az identity show --name github-actions-mi --resource-group myRG --query principalId -o tsv)

# Add federated identity credential to an existing app registration
az ad app federated-credential create \
  --id <app-registration-id> \
  --parameters "{
    \"name\": \"GitHubActionsFIC\",
    \"issuer\": \"https://token.actions.githubusercontent.com\",
    \"subject\": \"repo:myorg/myapp:ref:refs/heads/main\",
    \"description\": \"GitHub Actions deployment\",
    \"audiences\": [\"api://AzureADTokenExchange\"]
  }"

Monitoring and Auditing Managed Identity Usage

Managed identities generate sign-in logs in Entra ID just like user accounts or service principals. Monitor these logs for unusual activity: tokens requested from unexpected IPs, failures due to missing RBAC, or expired identity assignments. Use Azure Monitor and Log Analytics to create alerts for managed identity sign-in failures. Enable diagnostic settings on Azure resources to log token acquisition attempts. For auditing, use Azure Activity Log to track managed identity creation, deletion, and role assignments. Key metrics to track: number of identities per subscription, identities with 'Contributor' or higher roles (over-privileged), and identities not used in 90+ days (zombie identities). Use Azure Resource Graph to inventory all managed identities across subscriptions. Periodically review and clean up unused identities to reduce attack surface.

// Find managed identities with high-privilege roles
authorizationresources
| where type =~ "microsoft.authorization/roleassignments"
| extend principalId = tostring(properties.principalId)
| join kind=inner (
    advisorresources
    | where type =~ "microsoft.managedidentity/userassignedidentities"
    | project identityId = id, identityName = name
) on $left.principalId == $right.identityId
| where properties.roleDefinitionId in (
    // Owner, Contributor, User Access Administrator
    "8e3af657-a8ff-443c-a75c-2fe8c4bcb635",
    "b24988ac-6180-42a0-ab88-20f7382dd24c",
    "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9"
)
| project identityName, role = properties.roleDefinitionName, scope = properties.scope