Configuring MSI – Azure

In Azure, you can often get access to a resource by getting its service key or connection string, which contains a token. While such an approach is super simple and saves time, it is really problematic when it comes to security management and granular access to the different features of a service.

At the time of writing this, a few months ago, Managed Identity (MI) was named Managed Service Identity (MSI). In some older publications, you can still see the old name but do not be confused  it is still the same feature.

Before we get started, I want to ensure that you understand all the pros and cons of MSI:

  • Addresses the problem of revoking access to services, which has limited capabilities when it comes to security (such as Azure Storage or Azure Cosmos DB)
  • Allows you to introduce identities to resources that did not have them previously
  • Gives you the capability to declare access to different services using RBAC and custom roles
  • Uses service principals to configure the feature, which is a well-understood feature of Azure
  • Complicates the process of delivering software as you have to configure all the identities first and define proper access
  • Introduces complexity when configuring local and cloud environments

Nonetheless, in most cases, the advantages outweigh the disadvantages. There is one more important feature here that you should become familiar with. MSI gives you two different types of identities:

  • System assigned identity: This particular identity is assigned to an Azure resource and tied to its whole life cycle.
  • User assigned identity: This is a kind of identity that can be attached and detached from a resource.

In this section, you will learn what MSI is and how you can use it. It’s one of the newer features available that introduces identities to Azure services and your applications, all of which can be managed via RBAC. Depending on your use case, different kinds of identities will suit your needs.

MSI is a feature that is still under development for many Azure services. Before you decide to implement your own method of authentication, consult the MSI documentation to make sure that it is not available for the services you are using.

To get started, you will need an actual resource that works with the MSI feature. One example of such a resource is Azure Virtual Machine. It is also available for other services such as Azure Cosmos DB and Azure App Services. For the purpose of this section, we will cover how to work with MSI using the latter service.

The main feature of MSI is giving an identity to a resource so that it can access other services without implementing the whole authentication logic. This can be done via provided endpoints, which allow a service to obtain an authentication token. That token allows services to access other resources (assuming you have granted access to them). Now, let’s learn how to use MSI to secure Azure App Services.

Securing Azure App Services

To get started with MSI, you will need a principal that can be used (or let Azure create an identity for us by using the system-assigned identity). To access this feature in Azure App Service, you will have to find the Identity blade in the portal:

Figure 5.6 – Identity blade

As you can see, by enabling a system-assigned identity on Azure App Service, it gets an Object ID, which is the identifier or the resource in Azure AD. If you go to the Enterprise applications feature in your Azure AD tenant, you will be able to find the application here:

Figure 5.7 – Enterprise applications blade

Of course, you do not have to assign a system identity to a resource – in all cases, you can leverage an identity you created previously by using a user-assigned identity.

Remember that services with identities can access all the Azure AD secured resources. If you assign it a wide set of permissions, you may face security issues.

When MSI is enabled, a service obtains a token from a special endpoint by using the object ID it has been assigned. By using the token, the service no longer has to store all the passwords and important configuration inside it – it can connect to Azure Key Vault and introduce itself as a service with a particular set of permissions. To read more about Azure Key Vault, go to

If you access, for example, Kudu (which is an additional layer for Web Apps hosted on Azure App Services) for Azure App Service, you will see that it now contains environment variables that can be leveraged to use the MI feature inside your application:

Figure 5.8 – Accessing Kudu from Azure portal

Unfortunately, to obtain a token from the endpoint, you will still have to implement a short snippet inside the application code (written in C#):

public static async Task <HttpResponseMessage> GetToken(string resource, string apiversion) {
var request = new HttpRequestMessage(HttpMethod.Get,String.Format("{0}/?resource={1}&api-version=2019- 08-01", Environment.GetEnvironmentVariable("IDENTITY_ENDPOINT"), resource));
request.Headers.Add("X-IDENTITY-HEADER", Environment.GetEnvironmentVariable("IDENTITY_HEADER"));

return await _client.SendAsync(request);

The preceding snippet is written in C#, but the feature will work with basically any language. It will be able to do one thing  send a REST request to the provided endpoint.

To find more examples, consult the following page in the documentation:

The response will look like this:

HTTP/1.1 200 OK
Content-Type: application/json

"access_token": "eyJ0eXAi…",
"expires_on": "1586984735",
"resource": "",
"token_type": "Bearer",
"client_id": "5E29463D-71DA-4FE0-8E69-999B57DB23B0"

Let’s explain this in more detail:

  • We are constructing the endpoint URL from the environment variable.
  • We are adding the X-IDENTITY-HEADER header to help the server secure itself against Server-Side Request Forgery (SSRF) attacks.
  • Once the access token is returned, we are returning it as the result of the method. The value of the resource parameter is the URL of the Azure service you want to get the token for (for example,
  • The actual token is passed via the access_token parameter.
  • When the response is returned, you can use it to authenticate your request to other resources by passing it in the Authorization header and prepending Bearer as the schema.

Using the access token only will not give you immediate access – you will have to give principal access to a service. To do so, consult the previous section about assigning roles to different identities. The scenario is a little bit different when using Azure Key Vault as you will have to explicitly assign a principal to the service by giving it a defined set of permissions. To do this, follow these steps:

  1.  Go to your Azure Key Vault instance and find the Access policies blade:

Figure 5.9 – Access policies blade
  1. When you click on it, you will see a new screen that shows all the policies that have been assigned to this particular instance of Key Vault. From here, you can click on the + Add new button, which will display the following form:

Figure 5.10 – Configuring an access policy

Once an application has been assigned to a Key Vault instance, it will be allowed to, for example, get and list keys or secrets. On the screen shown in the preceding screenshot, you will have to configure the following:

  • Select principal: The service principal who will have that policy assigned to them.
  • Key/Secret/Certificate permissions: Configuration of permissions for different areas inside Key Vault.

This pattern is really helpful when you have many applications that store passwords in databases or other systems and want to improve security. I strongly recommend that you use it so that you can be sure that they are stored in a secure fashion and that only a limited number of entities can access them. 

In this section, you had a chance to use the MSI feature to configure access to your services without implementing your own logic. The next section will cover how to secure access in Azure using Shared Access Policies, which are available for Azure Storage.

Related Articles

How to add swap space on Ubuntu 21.04 Operating System

How to add swap space on Ubuntu 21.04 Operating System

The swap space is a unique space on the disk that is used by the system when Physical RAM is full. When a Linux machine runout the RAM it use swap space to move inactive pages from RAM. Swap space can be created into Linux system in two ways, one we can create a...

read more

Lorem ipsum dolor sit amet consectetur


Submit a Comment

Your email address will not be published. Required fields are marked *

twenty − nineteen =