Managed Identity vs Service Principals
Managed Identity removes secrets from your workloads. If you're still rotating client secrets for an Azure-hosted app, you're carrying an unnecessary risk.
Deep dive
Two flavours
- System-assigned: lifecycle tied to the resource. Deleted with it. Best for single-resource workloads.
- User-assigned: standalone identity you attach to multiple resources. Survives pod/VM recreation. Best for AKS workloads or anywhere identity should outlive compute.
How it works
The platform injects credentials via IMDS (169.254.169.254). The Azure SDK (DefaultAzureCredential) picks them up automatically — same code works locally (developer creds) and in prod.
AKS specifics
Use Workload Identity (federated OIDC), not the deprecated pod identity. Annotate the Kubernetes ServiceAccount with the Azure client ID; pods get a projected token; SDK exchanges it for an Azure AD token.
Real-world example
From productionAudit found 60+ active service principal secrets across the org, half past rotation policy. Migrated AKS workloads to Workload Identity over a quarter. Secret-leak surface went from 60 long-lived secrets to zero for those workloads. The remaining service principals were for cross-tenant integrations where MI doesn't apply.
Interview questions
2 senior-levelQ1Managed Identity vs Service Principal?▾
MI is a service principal whose credentials are managed by Azure and never exposed to you. Use it whenever the workload runs in Azure. Service principals are still needed for external systems (GitHub Actions to Azure, on-prem) — and even then prefer OIDC federation over client secrets.
Q2How does Workload Identity work in AKS?▾
AKS issues OIDC tokens for service accounts. Azure AD trusts that issuer via a federated credential. Pods get a projected token, the Azure SDK exchanges it for an AAD access token. No secrets stored anywhere.
Common mistakes
Granting Managed Identity
Contributorat subscription scope.Using system-assigned identity on pods (lifecycle mismatch).
Trade-offs
MI couples you to Azure — for portability across clouds, OIDC federation patterns generalize better.