Azure identity design<\/a> should prefer managed identity, workload federation, and Entra-based authorization where supported before creating another application password.<\/p>\nFor current Azure security architecture, the durable pattern is credential-free authentication plus explicit least-privilege authorization. Managed identities solve credential handling; careful RBAC and lifecycle are what solve privilege.<\/p>
User-assigned identity reuse should be intentional. Sharing one identity across several instances of the same stateless service can simplify permission management, while sharing it across unrelated applications creates a large blast radius. Give the identity one coherent job and document which resources are allowed to attach it.<\/p>\n
System-assigned identities are useful for strict one-to-one lifecycle because deletion of the Azure resource deletes the identity. This can simplify cleanup for ephemeral resources, but it also means role assignments need to be recreated when the resource is redeployed with a new principal.<\/p>\n
Identity creation and identity assignment are separate privileges. Azure provides roles such as Managed Identity Contributor and Managed Identity Operator so platform teams can delegate creation or attachment without granting full subscription ownership. Use those distinctions to avoid making every deployment pipeline an identity administrator.<\/p>\n
Role assignment itself should follow separation of duties for sensitive workloads. A team may be able to deploy an application and attach an approved identity without being able to grant that identity new subscription-wide permissions. This prevents deployment authority from silently becoming privilege-escalation authority.<\/p>\n
Credential-free code should use the Azure Identity libraries or service-specific connectors that support managed identity. Avoid fallback logic that silently uses a developer’s personal credential or an embedded key in production. The application should fail clearly when the intended identity cannot obtain a token.<\/p>\n
Managed identities need monitoring. Track role assignments, changes to identity attachments, failed token acquisition, unusual access to downstream resources, and identities with no active workloads. An identity with no password can still be abused if its attached compute is compromised or its permissions are excessive.<\/p>\n
Cross-tenant and application scenarios may require a user-assigned managed identity to act as a federated credential for an Entra application. Microsoft’s current guidance supports this pattern in specific scenarios, allowing the Azure-hosted workload to exchange a managed-identity token for an application token without storing an app secret.<\/p>\n
Workload identity federation for GitHub Actions, Kubernetes, and other external platforms should use narrow subject and issuer trust. A broad federated credential can let more workloads impersonate the application than intended. Review federation rules with the same rigor as RBAC role assignments.<\/p>\n
Least privilege should be verified continuously. Permissions accumulate as features are added, incidents are debugged, and teams change ownership. Periodic review should identify identities with roles no longer used, overly broad scopes, or old attachments that persist after a service was retired.<\/p>\n
Managed identity inventory should be part of cloud hygiene. Identify identities with no attached resources, identities with subscription-wide roles, and user-assigned identities shared by unrelated workloads. Those patterns often reveal privilege that grew through convenience rather than design.<\/p>\n
Deployment automation should assign roles at the narrowest scope known at deployment time. Avoid granting a broad resource-group role first and promising to narrow it later; temporary permissions are easy to forget once the application works.<\/p>\n
When a service does not support Entra authentication, keep the exception visible. The workload may still need a secret or certificate, and that credential should have a rotation and storage design rather than being hidden inside otherwise credential-free architecture.<\/p>\n
For current Azure workloads, managed identity is best viewed as the authentication primitive, while least privilege is the authorization discipline. Both are required. Removing secrets without reducing role scope solves only half of the security problem.<\/p>\n
Identity naming should express workload purpose and environment. Clear names make role assignments easier to review and reduce the chance that a generic user-assigned identity is reused simply because nobody remembers what it was created for.<\/p>\n
When a managed identity is retired, remove its role assignments and federated trusts as well as detaching it from compute. Cleanup should close the authorization path, not merely delete or disable the resource that most obviously used the identity.<\/p>\n
Role assignment review should distinguish identity ownership from resource ownership. The team that owns the application may know what the workload needs, while the team that owns the database or vault decides what operations are acceptable. Approval across both sides reduces accidental over-permissioning.<\/p>\n
Prefer built-in roles where they match the workload, but use a custom role when existing roles bundle permissions the application does not need. Custom roles create maintenance cost, so document the operations and review them when the target service adds new API capabilities.<\/p>\n
Least privilege should also cover token audience and downstream API permissions. A managed identity that can request a token is not enough; the receiving service should enforce the narrow role or application permission that matches the workload’s business action.<\/p>\n
Review managed identities whenever workloads are merged, split, or retired so authorization follows the current architecture rather than the history of how the service was first deployed.<\/p>\n
Keep one owner for every reusable user-assigned identity so attachment, role changes, incident response, and retirement do not become orphaned platform responsibilities.<\/p>\n
Review role scope before every major workload expansion or cross-service integration.<\/p>\n
Keep identity inventory current.<\/p>\n
Review continuously.<\/p>","protected":false},"excerpt":{"rendered":"
Managed identities remove one of the most common cloud-security problems: application credentials that have to be created, stored, rotated, and distributed. An Azure resource with a managed identity can request Microsoft Entra tokens and access supported services without the application holding a reusable password or certificate. That does not make the workload secure automatically. A managed identity is still a service principal with permissions. The architectural value appears when credential-free authentication is paired with narrow RBAC scope, clear lifecycle, explicit identity selection, and periodic review of which resources the workload…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11633","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t