Overview
First, what the heck fire is Managed Identity, and why will it make your life easier? A Managed Identity allows your application, e.g., Logic App, Function App, to securely access other Azure Active Directory (AAD) protected resources. Azure manages the Identity so you don’t have to mess around storing or rotating secrets or tokens. Wait a minute, how can something set up just once be secure over time? Didn’t we have to rotate secrets for a reason? Well, Azure AD does all that for you. Nice!
Managed Identity Types
Managed Identities come in two flavours:
- System-assigned
- User-assigned
System-assigned Managed Identities are tied to a specific resource, e.g., a Logic App. The identity is created and deleted with the resource. I have taken the liberty and lifted images from the Managed Identity section of the online Microsoft Documentation because, well, they nicely illustrate the concepts. Using System-assigned Managed Identities helps control access from individual resources to other resources using role assignments as illustrated below.
Figure 1 System Assign Managed Identities
User-assigned Managed Identities, on the other hand, are created as independent entities. This can simplify setup and management. The following diagram shows a single User-assigned Managed Identity doing the job of the four System-assigned Managed Identities above.
Figure 2 User-Assigned Managed Identity
I’m a big fan of User-assigned Managed Identities because they are managed separately from resources that use them. Permissions are assigned to a User-assigned Managed Identity using Role-Based Access Control (RBAC). These permissions can be set up in advance, even before the resources they will be securing have been created. Setting up permissions in advance has at least two advantages. 1, the target resources don’t have to exist at the time, and 2, a separate team can manage security. That’s great for organisations that separate these responsibilities from the development team. So, does that mean you no longer need to bother with System-assigned Managed Identities? No, they still have their place. If your resource has its own identity or a unique set of permissions, and you want the identity deleted when the resource is deleted, then use a System-assigned Managed Identity.
User-assigned Managed Identity Scenarios
A User-assigned Managed Identity is excellent for managing a range of scenarios. For example, suppose you have a bunch of Logic Apps that require the same level of access to a particular resource, say, a storage account. In that case, a single User-assigned Managed Identity can be given appropriate RBAC roles, and all the Logic Apps can use that identity. If a new Logic App comes along that also needs that access, then you simply assign the Managed Identity to it and your security is done. What’s also cool, is that a resource may be assigned multiple User-assigned Managed Identities. This approach can give different levels of access to different sets of resources. The following diagram shows how a group of virtual machines (or Logic Apps) all have access to storage account 1 and key vault 1, but only the last two VMs have access to the second storage account and second key vault.
Figure 3 Multiple Manage Identities
Quirks and Limitations
Not all resources support Managed Identities, but the list is growing (link showing full list). Only recently has support for User-assigned Managed Identities been added to Standard Logic Apps. They work perfectly well, but the connections file does not support automatic interpolation of app config references. This is a pain when trying to set up your deployment pipelines. Hopefully, by the time you read this the issue has been fixed.
In Summary
Managed Identities are the best approach to securing your resources without the hassles of secret management. RBAC adds a fine-grained level of control and security can be managed separately from the resources themselves.
