Spent last night shift untangling a web of service accounts and key vault access. The core confusion? When to use a Service Principal (SP) versus a Managed Identity (MI) in Azure. They both let non-human things (apps, VMs) access Azure resources, but the operational difference for us on-call folks is huge.
Think of a Service Principal as a traditional service account. You create it, **you are responsible for its credentials** (secrets or certificates). You must store, rotate, and secure them. It's a standalone identity that can have permissions assigned to it.
A Managed Identity is Azure's managed service account. Azure creates and manages the credentials for you—automatically rotates them, never shows them to you. It's intrinsically tied to an Azure resource (like a VM, App Service, or Function). You just turn it on and assign permissions.
**The critical difference is credential management.**
* **Service Principal:** You handle the secret/cert. You store it in your app config, Key Vault (but then need another secret to access *that*...), etc.
* **Managed Identity:** Azure handles the secret. Your code just asks the local Azure Instance Metadata Service (IMDS) for a token.
Example for a VM needing to read from a Storage Account:
```bash
# With a Managed Identity on the VM, your code just gets a token from the local endpoint.
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource= https://storage.azure.com /' -H Metadata:true
```
**When to use which?**
* Use a **Managed Identity** whenever your workload runs *inside Azure* on a supported service (VM, App Service, AKS, etc.). It's the most secure and operationally simpler choice. No secrets to leak.
* Use a **Service Principal** when your workload runs *outside Azure* (on-prem, another cloud) or on an Azure service that doesn't yet support Managed Identities. You're forced back to managing credentials yourself.
Bottom line for SRE/on-call: Prefer Managed Identities aggressively. It eliminates entire classes of incidents related to expired secrets and leaked credentials. One less thing to page you about at 3 AM.
zzz
Sleep is for the weak
I'm a senior platform engineer at a mid-size logistics company, where I manage our Azure spend and identity across about 150 VMs and 70+ app services that handle our real-time tracking and billing systems.
**Core Comparison**
1. **Credential Overhead and Security Risk**
A Service Principal requires you to generate and store a client secret or certificate. You are responsible for its secure storage (like in a CI/CD variable or Key Vault) and mandatory rotation, typically every 1-2 years. This creates a secret management chain; if you store the SP secret in Key Vault, you need another credential to access it. A Managed Identity has no credentials for you to manage. Azure automatically rotates the underlying credentials every 45 days, and they are never exposed in your code or configuration.
2. **Deployment and Configuration Effort**
For a Service Principal, you must manually create the app registration, generate a secret, assign RBAC roles, and then integrate that secret into your application's configuration. For a Managed Identity, you enable it with one click in the portal or a single CLI command (e.g., `az vm identity assign`) and then assign RBAC roles directly to that resource's identity. The integration code is simpler, using a standard library to call the local IMDS endpoint.
3. **Operational Scope and Portability**
A Service Principal is a standalone identity object that can be granted access to any Azure resource, independent of any single compute host. It's portable and can be used by applications running anywhere, including on-premises or in other clouds. A Managed Identity is intrinsically bound to a specific Azure resource (like one VM or one App Service instance). You cannot directly use a VM's Managed Identity from code running on a different VM.
4. **Cost and Licensing Impact**
Both are core Azure Active Directory features with no direct incremental cost. The indirect cost is in operational labor. In my last shop, we calculated approximately 4-6 hours per quarter per service principal for secret rotation, validation, and associated pipeline updates. Managed Identity eliminates that labor entirely. There is no license distinction; both use your existing Azure AD tenant.
My pick is Managed Identity for any workload running on a supported Azure resource (VM, App Service, Function, AKS pod). The elimination of secret management is the decisive factor. Only use a Service Principal if your code runs outside of Azure's managed compute services or if you need a single identity to be shared across multiple, disparate compute resources.
Every dollar counts.
Okay, that's a really helpful way to frame it - "you handle the secret" vs "Azure handles the secret." Makes the mental model much clearer.
So if I'm understanding right, a managed identity is almost always the better choice when your app or script is actually running inside Azure itself, right? Because you get the security benefit without the operational headache.
But when would you absolutely *need* a service principal? Is it only for things running completely outside of Azure, like a local development machine or a server in another cloud? Trying to figure out where the hard line is.