What are Managed Identities for Azure Resources?

The basic and most common problem for the developers is to manage and secure the credentials and other application related secrets within their code when they are building cloud- native, mission-critical applications. Although there could be number of uses, but generally these credentials are used for authenticating the application to other cloud services and connectivity to the database, but that definitely makes the application vulnerable and pose a threat to security and the security team will never welcome it. Wouldn’t it be great if the need for storing the credentials and other application secrets within the application could be wiped out, making the application more secure? Well, for that managed identities are there to help that makes your task easier and also helps to keep your security teams, happy.

Let’s see the topics that we will cover in this course. We will first try to understand managed identities, followed by the types of managed identities available along with their differences. Next, we will try to understand the benefits of using Managed Identities. Finally, we will then see Managed Identities in action where we will configure managed identities for Azure resources and understand how secure connections are established.

By the end of this course, you will have a solid understanding on Managed Identities and will be comfortable to use managed identities to keep your application code free from credentials and other secrets, while working with other instances of Azure services that rely on the Azure AD authentication and role-based access control.

Setting up the Stage

It is better to understand the managed identities with an example. Consider there is an organization CloudNext, which has a B-2-B business model having multiple partners. The IT department at CloudNext is planning on building a secure internet application on Azure to have an online presence in order to ease up and to expand their areas and regions of business.

As a first step, they create a blueprint of the application followed by the architecture. The solution looks promising, with multiple features. A team of developers start to build the application modules and after 4 months time all the modules of the application are complete, but before the application could be launched, it needs to pass through the security scanner in order to get the security teams blessings.

The security team discovers that the passwords and other connection string secrets are stored in the configuration file within the application itself and in some other places within the code. Security team, therefore, raises a red flag and refuses to approve the deployment of the application to the production stating security reasons, which obviously is the right thing. This must have been planned.

This was a clear miss and the team indeed needed to think through the alternate solution on how they can remove the secrets and credentials from within the application and still be able to securely connect to other Azure services and database to be used.

They start to lookout for any feature in Azure that could help them resolve their problem. This is when they come to know about Azure Key Vault. They were happy as all the application secrets and credentials could be stored and managed within the key vault and it can be accessed from inside the application to connect to other Azure services and database.

It was definitely an improvement but the application still needed a way to authenticate to Azure Key Vault to retrieve the keys, and other secrets. It means that the application stores key vault configuration within the application. Now what?

Understanding Managed Identities

The development team at CloudNext discovers that they can get away with the credentials and secrets stored within their code and instead leverage managed identities to  overcome such security issues. The development team now makes all the changes, removes all the stored credentials and passwords, and uses managed identities with Azure Key Vault. The application is again reviewed by the security team and this time everyone is happy and the security team blesses the application and gives a go-ahead for the application to be deployed onto production so that CloudNext Partners could easily and securely access the application.

Managed Identities are really very powerful as it levitates you from managing those identities and other overheads associated with credential management. The code remains clean and the Azure Key Vault can now be accessed without maintaining any configurations for the key vault within the code. Not just that, as I already mentioned, other Azure resources that support Azure AD authentication can now be accessed without having to store there connection string or other secret keys. For example – the application code can now access SQL database via the Key Vault or directly as it supports Azure AD authentication.

Types of Managed Identities and their differences

These managed identities are of two types:

1. System assigned identities
2. User assigned identities

System-assigned Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity an identity is created in Azure AD that is tied to the lifecycle of that service instance. So when the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.

User-assigned You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more instances of an Azure service. In the case of user-assigned managed identities, the identity is managed separately from the resources that use it.

Managed identities for Azure resources is the new name for the service formerly known as Managed Service Identity (MSI).

Benefits of using Managed Identities

So, what benefits do you get when using managed identities?

1. Obviously the primary benefit is that you get rid of storing the credentials and secrets within your code, so security is not a concern from that perspective. Simply put, you get improved security. If we talk about system assigned managed identities, they are not even accessible to you.
2. That gives another benefit. For system assigned managed identity, you get rid of the overhead of managing the  credentials as you do not have access to the secrets.
3. You can use these managed identities to authenticate to any azure resource that support Azure AD authentication. You just need to assign them the RBAC role on that resource and this is what we will see in the demo so it becomes crystal clear to you.
4. There is no additional cost for using managed identities.

Demo: Configuring Managed Identities