App Service UAMI at Management Group Scope: Token Theft

The Trap

User-Assigned Managed Identity (UAMI) role assignments made at Management Group scope, attached to an Azure App Service instance that also exposes an unauthenticated local token endpoint to anything running inside the worker process.

The Default State

Platform teams standardising multi-subscription deployments often create one shared UAMI, attach it to dozens of App Service instances via az webapp identity assign --identities, and then grant that identity Contributor or Reader at the Management Group level so nobody has to repeat role assignments per subscription. App Service exposes the token via the IDENTITY_ENDPOINT and IDENTITY_HEADER environment variables (the successor to the older MSI_ENDPOINT), reachable from any code executing in that worker with no additional authentication beyond the header value already sitting in the process environment.

The Blast Radius

Any remote code execution, server-side request forgery, or vulnerable dependency inside that single App Service instance lets an attacker call the local identity endpoint, retrieve an access token scoped to the UAMI’s assigned roles, and use it directly against Azure Resource Manager. Because the role assignment sits at Management Group scope, the stolen token is valid across every subscription nested beneath it, not just the one hosting the compromised app. Subscription-level network controls, NSGs, and even Conditional Access policies never trigger, because the token issuance is a loopback call to the App Service platform’s own metadata service, not a route that crosses a monitored boundary. Incident responders scoping containment to the affected resource group or subscription will miss the actual exposure entirely.

The Lead Mechanic Fix

Never assign roles to a UAMI above subscription scope, and prefer resource-group scoping wherever the workload allows it. Replace the shared identity with one UAMI per subscription: az identity create --name uami-sub-prod --resource-group rg-identity, then bind roles narrowly: az role assignment create --assignee-object-id <principalId> --assignee-principal-type ServicePrincipal --role "Contributor" --scope /subscriptions/<subId>/resourceGroups/<rg>. Enforce this with an Azure Policy definition using deny effect on Microsoft.Authorization/roleAssignments where scope matches /providers/Microsoft.Management/managementGroups/* for principals of type ServicePrincipal. Audit existing exposure with az role assignment list --all --query "[?principalType=='ServicePrincipal']" filtered against Management Group scopes, and rotate any UAMI found there onto per-subscription identities immediately.