Azure Managed Identities, What? Why? & When?

Azure Managed Identities is an re-brand of a service that was introduced about 1 year back called Managed Service Identities (MSI). Now with Azure Managed Identities you have the same functionality of what MSI used to be and much more. Let’s look at what Managed Identities for Azure Resources is.

What?

Azure Managed Identities is a feature provided by Azure AD that providers Azure Services with an automatically managed identity that can be used to access other Azure AD Authentication supported services.

It’s a combination of Azure AD Authentication and Azure RBAC (Role Based Access Management). You use Azure AD for authentication and then use RBAC for authorize access to the services you want to access. And the beauty of Managed Identities its completely managed by Azure AD, you don’t have to worry about the lifecycle of the Identities and the credential management.

Types of Managed Identities

There are 2 types of Managed Identities you can use depending on your requirement

System-Assigned Managed Identities

These identities are enabled directly on the Azure Services (e.g on Azure Virtual Machines, App Services etc.) And the lifetime of these Identities is directly tied to the service that the identity was enabled on. The following are some of the attributes of System Assigned Identities.

• Enabled directly on the Azure Service instances
• Lifetime of the identity is directly tied to the Azure Service it was enabled on
• You can not share these identities between multiple instances. It’s only tied to 1 Azure Service instances
• The credentials are managed directly on the Azure Service instance where the identity was enabled on.

User-Assigned Managed Identities

These identities are created just like normal Azure Service instances. So, these are not tied to any particular Azure Service instance and therefore the lifetime is managed separately. Following are some of the attributes of User Assigned Managed Identities

• Created as a separate Azure Resource (just like provisioning a service like an App Service Instance)
• Lifetime of the identity is not tied to any Azure Service Instance.
• You can share the same identity across multiple Azure Service Instances.

Why?

One of the most common problem is managing the credentials you use to connect to other services in your application. Regardless of the service you communicate with resides in the same cloud or as a third party, you need to securely communicate with these services and the credentials, API Keys, connection strings etc. that is used in this secure communication needs to be protected. This provides an overhead for the engineers regardless if you are an application developer or an operations engineer.

You can never store the credentials on the local development machine, you can never check them in to your source control, you need to think about using Key Rotation in order to protect your keys. But with Managed Identities you do not need to worry about all these aspects, since the identities you use is automatically managed, Azure takes the responsibility of securing them and aspects like key rotation. So you just need to focus on building awesome features for your applications.

You don’t have to change your development workflows to use these Identities, they will remain the same, You don’t even have to know how the managed identities work behind the scenes, coz the SDKs provided for you will handle all of these for you. So, there is no reason or an excuse for not to use Azure Managed Identities in your applications.

If you want to know more about how the managed identities work behind the scenes, I will link one of my previous articles on that describes the process. It has not changed. Check out How This Work section for more details.

When?

You need to know when to use the different types of Managed Identities. The different types of managed identities are useful for certain scenarios.

Use System-Assigned Managed Identities

System Assigned Identities are good when you have workloads that will only run on a single instance. For example, let’s say that you have a small background service that needs to run on a single Azure Virtual Machine. This is a good candidate for using System-Assigned managed identities. Remember system assigned identities can not be shared with other Azure Service instances. But if you are limited to running your workload in a single instance then this I great since the identity is directly connected to your instance and you don’t need to worry about cleanup.

Use User-Assigned Managed Identities

In a scenario where your application runs on multiple instances, for example you have an ASP.Net Core application that is distributed across many data centers around the globe running on 20-30 instances, In this case you its better to use a User-Assigned identity since that identity can be shared between all these instances and you need to only give authorization permissions for one identity. And all the applications running on the 20-30 instances can access the Azure Service using that single User-Assigned Identity.

But if you are using a System-Assigned identity, you will need to authorize all of the individual System Assigned identities that will be created for your 20-30 instances.

Summary

I think now its clear to you how Managed Identities for Azure Resource work and how you can leverage Managed Identities depending on the scenario your application is in. Regardless if your application is a large-scale enterprise grade application or a simple application, managing credentials is important and its best for us not to have that responsibility and hand it over to a service like Managed Identities.