4.1. Identities for Applications and Azure Workloads

💡 First Principle: Anything that authenticates needs an identity — and for software, the worst identity is a borrowed human one. Workload identities exist so code can hold its own narrowly-scoped access, and the best of them (managed identities) eliminate the credential entirely: nothing to store means nothing to leak.

The stakes are concrete: connection strings in source control, service-account passwords in wikis, certificates that expire at 2 AM — credential sprawl is how attackers pivot from one leaked secret to a subscription. Every choice in this section is a step down the ladder of stored secrets: user account (worst) → service account with password → service principal with certificate → managed identity (no credential you ever see).

⚠️ Common Misconception: "Managed identities work anywhere our code runs." They are bound to Azure resources — a VM, App Service, Function, Logic App — which acquire tokens through a local, Azure-provided endpoint. Code on-premises or in another cloud cannot use one; it needs a service principal (ideally with federated credentials rather than secrets).