Overview
This pattern describes how to organize and manage Azure Managed Identities so that they clearly map to an application’s lifecycle and dependencies.
Instead of binding a system-assigned identity directly to each resource, a user-assigned managed identity is created in the same resource group as the application it serves.
When the application is decommissioned, the entire resource group (including the managed identity) is deleted, ensuring clean lifecycle management.
Purpose
- Clarity: Easily see which identity belongs to which application.
- Reusability: Allow new versions or instances of the same app to reuse the same identity without redefining permissions.
- Clean lifecycle: When deleting the app’s resource group, the managed identity and all associated resources are removed together.
- Reduced dangling permissions: Prevents unused service principals with lingering access rights.
Pattern Summary
- Create a user-assigned managed identity in the same resource group as the application.
- Assign RBAC permissions for that identity to the resources it needs to access (e.g., Key Vault, Storage Account, SQL Database).
- Configure the application (e.g., Azure Function, App Service) to use the managed identity for authentication.
- Deploy new versions of the application by attaching them to the same managed identity.
- Decommission the application by deleting the resource group, which also removes the managed identity and cleans up associated rights.
Example – Azure Function Accessing Key Vault
Scenario:
An Azure Function needs to read secrets from a Key Vault.
Steps:
- In the same resource group as the Azure Function, create a user-assigned managed identity:
az identity create \
--name myApp-mi \
--resource-group myApp-rg
- Assign the identity Key Vault Secrets User role:
az role assignment create \
--assignee <principalId-of-mi> \
--role "Key Vault Secrets User" \
--scope /subscriptions/<sub-id>/resourceGroups/myApp-rg/providers/Microsoft.KeyVault/vaults/myApp-kv
- In the Azure Function configuration, enable Managed Identity and attach the user-assigned identity.
- In code, authenticate using the DefaultAzureCredential or ManagedIdentityCredential class from the Azure SDK.
Advantages
- Version Independence: New app versions can reuse the same identity without reassigning permissions.
- Logical Grouping: All app resources, including the identity, are in one place.
- Governance Friendly: Easier auditing of who/what has access to a given resource.
- No Manual Secret Rotation: Managed identities handle token issuance and rotation automatically.
When Not to Use
- For single-use throwaway resources where the identity’s lifecycle truly should match the resource.
- When cross-application sharing of a managed identity is required (use a separate shared identity in a governance resource group instead).
Visual Diagram
[ Resource Group: myApp-rg ]
├── Azure Function: myApp-func
├── User-Assigned Managed Identity: myApp-mi
└── Key Vault: myApp-kv
myApp-func → uses myApp-mi → RBAC → myApp-kv
