Managed identities & SP escalation

Kill client secrets; watch credential injection.

Expert35 min · lesson 3 of 15

The Azure equivalent of "delete the long-lived keys" is: use managed identities and federated credentials instead of service-principal client secrets. Where secrets or over-broad identity permissions remain, they become the escalation and leakage paths.

Managed identities over client secrets

A managed identity gives an Azure resource an Entra identity whose tokens Azure issues and rotates automatically — nothing to store or leak. System-assigned identities live and die with one resource; user-assigned identities are standalone objects you can share across resources and manage independently. Either way, you assign the identity RBAC roles at a scope, and the app fetches tokens from the local metadata endpoint with no secret in code or config. For workloads outside Azure, workload identity federation exchanges an external OIDC token for Azure access with no secret at all.

a managed identity with scoped access

# Give a Function app a system-assigned identity and grant it ONE vault's secrets.
az functionapp identity assign -g rg -n payments-fn
PRINCIPAL=$(az functionapp identity show -g rg -n payments-fn --query principalId -o tsv)
az role assignment create --assignee-object-id $PRINCIPAL \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/SUB/resourceGroups/rg/providers/Microsoft.KeyVault/vaults/app-kv
# The app calls the local token endpoint — no client secret anywhere in config.

The service-principal credential escalation

The classic Entra escalation is credential injection: a principal who can add a new client secret or certificate to an existing, privileged service principal or app registration can then authenticate as it and inherit its permissions. Application Administrator and similar roles carry this power. Restrict who can manage app credentials, prefer federated credentials over client secrets, set short secret lifetimes where secrets are unavoidable, and alert on new credentials being added to any privileged service principal.

A service-principal credential escalation

1principal can manage app creds

e.g. Application Administrator

2adds a secret to a privileged SP

new client secret / cert

3authenticates as that SP

client-credentials flow

4inherits its permissions

escalation complete

Managed and federated identities remove the secret entirely. Where app credentials exist, tightly control who can add them and alert when they do.

A shared or long-lived client secret is a durable key

A service-principal client secret is a bearer credential that works until it expires or is deleted — commit or paste it once and it is compromised. Replace client secrets with managed identities (in Azure) or federated credentials (outside Azure); where a secret is unavoidable, keep it in Key Vault, scope it, and rotate it on a short cycle.

Azure RBAC, scope & deny…NSGs, ASGs & no public management