Managed identity should be used in function apps

What does the recommendation "Managed identity should be used in function apps" check?

Flags any function app whose 'identity' property has no system-assigned or user-assigned managed identity attached, so the app has no platform-managed Microsoft Entra ID it can use to authenticate outbound to other Azure services. It checks only that an identity exists on the resource. It does not verify that your function code actually uses it, that role assignments are scoped correctly, or that connection strings and keys have been removed from app settings. An app can therefore pass this control and still authenticate to everything with secrets, so treat it as a precondition for secret-free auth rather than proof that you have achieved it.

Why does "Managed identity should be used in function apps" matter?

Without a managed identity, a function typically reaches storage, Key Vault, SQL or Service Bus using connection strings, account keys or client secrets held in application settings. Those credentials are long-lived, copied into deployment pipelines and rarely rotated, so a leaked app setting or a compromised pipeline hands an attacker durable access that outlives the breach. Because function app settings are readable by anyone with contributor rights on the resource, the secret also widens who can impersonate the workload internally. A managed identity removes the secret entirely: Entra ID issues short-lived tokens the platform rotates automatically, shrinking both the blast radius and the audit burden when something does go wrong, and giving you a single principal to govern with conditional access and access reviews.

How do I fix "Managed identity should be used in function apps"?

1. Enable a system-assigned identity for the simplest case: 'az functionapp identity assign --name <app> --resource-group <rg> --identities [system]', or set 'identity: { type: SystemAssigned }' in Bicep. Use a user-assigned identity instead when several apps must share one identity or you need it to exist before the app is created.
2. Grant that identity least-privilege access on each target resource via Azure RBAC role assignments (for example 'Storage Blob Data Contributor' or a Key Vault data-plane role) rather than reusing a broad owner-style role.
3. Repoint the code and bindings to token-based auth, for example using DefaultAzureCredential, then delete the now-redundant connection strings and account keys from the function app's application settings so no fallback secret remains.

# 1. Give the app its own identity and capture the principal ID.
principalId=$(az webapp identity assign \
  --resource-group payments-rg \
  --name payments-api-prod \
  --query principalId -o tsv)

# 2. Grant least privilege on the exact resource it uses (not the subscription).
az role assignment create \
  --assignee-object-id "$principalId" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/payments-rg/providers/Microsoft.Storage/storageAccounts/paymentsdata"

# 3. Only after the code uses DefaultAzureCredential and the new path is verified,
#    delete the stored secret so there is nothing left to leak.
az webapp config appsettings delete \
  --resource-group payments-rg --name payments-api-prod \
  --setting-names StorageConnectionString

# 4. Ratchet it shut: audit any future app created without a managed identity.
az policy assignment create \
  --name audit-webapp-managed-identity \
  --policy 2b9ad585-36bc-4615-b300-fd4435808332 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"