Inside Out Security Blog   /   Active Directory

Azure Managed Identities: Definition, Types, Benefits + Demonstration

The most frequent issue developers have to contend with when it comes to securing communication between different services and devices is the management and securement of credentials, keys, certificates, and secrets within their cloud-native applications. However, storing these credentials, secrets, and keys directly within the application code can expose the app to security threats. 

Removing these credentials from the code tightens the application’s security, but now how will you manage these credentials, keys, and secrets? This is where managed identities come into play. Using managed identities eliminates the requirements for developers to wrangle all this information manually.

What are managed identities in Azure?

Managed identities remove the overhead of manually managing credentials, secrets, passwords, and keys within the application’s code. Instead, this information is automatically managed within Azure Active Directory (AD) when connected to resources that support AD authentication. Managed identities can be used to request and receive Azure AD tokens without any requirement to govern credentials, secrets, keys, and passwords.

Azure Key Vault is an alternative solution to store and manage an application’s secrets and credentials. In this instance, the information is stored within the key vault. However, the application will still need to authenticate to Azure Key Vault to retrieve the keys and other secrets, meaning the application will still house important information directly within the application code.

Managed identities for Azure resources — the new name for the service formerly known as Managed Service Identity (MSI) — are extremely powerful and reduce the workload associated with manual oversight. The code remains clean, and if using Azure Key Vault, its configurations are not required to be maintained within the code. You can also access other Azure resources that support AD authentication without storing their respective connection strings and other configuration details within the application. You can perform operations on managed identities using the Azure portal, an ARM template, Azure CLI, PowerShell, and REST APIs.

Types of managed identities and their differences

There are two types of managed identities: 

1. System-assigned managed identities
2. User-assigned managed identities

Both of these identities have their own flavors, and each one comes with its own pros and cons. Let’s go over the features and differences between the two types of identities.

System-assigned managed identities

You can enable system-assigned managed identities on some of the most commonly used Azure services. Upon enabling within the Azure service instance, an identity is created in Azure Active Directory — the service principal for that service instance. 

The identity is also tied to the lifecycle of the service instance, meaning it will be automatically removed when the service instance is deleted or decommissioned. When the identity is deleted, the corresponding service principal is also deleted in Azure AD. 

User-assigned managed identities

Another way of using managed identity for Azure resources is by creating a user-assigned managed identity separately and then assigning it as a standalone Azure resource. The best part of this method is that you can assign the same managed identity to more than one Azure service or more than one instance of the Azure service. Because the user-assigned managed identity is created separately, it is not deleted when the Azure resource associated with it is deleted or decommissioned. 

Differences between system- and user-assigned managed identities

For the complete list of Azure services that support managed identities, click here.

One important point to remember is that a managed identity, be it system-assigned or user-assigned, is a special kind of service principal used only with Azure resources.

As they are in sync, modifications of one may affect the other. For instance, the service principal is removed when the corresponding managed identity is deleted.

How do managed identities work?

Through managed identities, you can request access tokens for the resources that support Azure AD authentication. 

Access tokens are received based on the RBAC assigned to them on the resource. Once the resource receives the access token, it can be accessed.. The best part is that Azure takes care of rolling the credentials the service instance uses, removing the slightest possibility of password leaks.

Seven steps to implement Azure managed identities:

• Step 1: Request is submitted for Azure Resource Manager to enable (in case of a system-assigned managed identity) or create (in case of a user-assigned managed identity) a managed identity.
• Step 2: In the case of the system-assigned managed identity, when the Azure Resource Manager receives a request to enable a managed identity on the VM, it creates a service principal for the managed identity within AD. The trusted Azure AD tenant will host the new service principal.
  • For user-assigned managed identities, the Azure Resource Manager receives the request to create the managed identity as a separate resource. When the user-assigned managed identity is created, a corresponding service principal is also created by the resource manager within the trusted Azure AD tenant.
• Step 3: For system-assigned managed identities, the resource manager updates the virtual machine identity using the Azure Instance Metadata Service (IMDS) identity endpoint. This configuration provides the endpoint with the service principal client ID and certificate.
  • In the case of user-assigned managed identities, when the resource manager receives the request to configure the user-assigned managed identity on virtual machines, the Azure Resource Manager subsequently updates the IMDS identity endpoint with the user-assigned managed identity service principal client ID and certificate.
• Step 4: After you create the service principal and enable or assign the virtual machine identity, you need to use the service principal information to assign an appropriate RBAC to the Azure resource.
• Step 5: The application code running on the VM requests a token from the IMDS endpoint, accessible only from within the virtual machine. Certain parameters are sent for token requests. They are:
  • Resource parameter: Represents the service to which the token is sent for authentication
  • API version parameter: Represents the IMDS version. Use api-version=2018-02-01 or higher
  • Client ID parameter: The service principal for the token-requested identity. This is only applicable to user-assigned managed identities, as that is the only option for assigning more than one identity to a single virtual machine
• Step 6: Access token request is sent to Azure AD using the client ID and certificate. Azure AD returns a JSON Web Token (JWT) access token.
• Step 7: The code now sends the Azure AD token to access the desired Azure service, so long as it supports Azure AD authentication.

Creating and configuring managed identities: Demonstration

Below are the steps to create, configure, and assign RBAC to managed identities.

1. Setting the scenario: Lab objectives
2. Prerequisites
3. Phase one: Working with system-assigned managed identities
4. Phase two: Working with user-assigned managed identities

Setting the scenario: Lab objectives

You can choose between configuring either the system-assigned or the user-assigned managed identity for your projects, based on your requirements and objectives. However, for demonstration purposes, this lab has two different sections.

In the first section, we’ll enable the system-assigned managed identity for a virtual machine on Azure and provide this service principal, contributor role on the storage account.

In the second part of the lab, we’ll create a user-assigned managed identity as a separate resource, assigning this identity to the virtual machine and assigning an RBAC to this identity on the storage account.

Prerequisites for the lab

1. An Azure subscription is required; click here to sign in
2. A virtual network
3. A virtual machine within the virtual network
4. A storage account for assigning the RBAC

Phase one: working with system-assigned managed identities

1. Sign in to the Azure portal and open the virtual machines page.

2. From the left-hand menu, click “identity” under settings.

3. Once you are on the Identity page, you will notice two tabs: One for the system-assigned user identity and one for the user-assigned identity.

4. While under the system-assigned tab, toggle the status button to “on.” Once done, click on the “save” button.

5. It will take a couple of seconds for the system-assigned managed identity to be provisioned.

6. Now, open the storage account page, and click on “access control (IAM)” from the left-hand navigation.

7. On the access control page, click on the “add” button from the top navigation and then click on “add role assignment.”

8. On the “add role assignment” page, choose a role you want to give to the created service principal and click on the “next” button at the bottom of the page.

9. Select the “managed identity” option under “assign access to,” and click on the “select members” link.

10. A pop-up will appear on the right-hand side. Choose “virtual machine” from the “managed identity” dropdown. The newly-created service principal for the virtual machine will appear for selection.

11. Select the correct service principal that appears and click on the “select” button.

12. Now click on the “review + assign” button.

13. Once you are on the confirmation page, click on the “review + assign” button again.

14. The subsequently-assigned role will be visible under the role assignments tab.

Phase two: working with system-assigned managed identities

1. On the virtual machine page, click on the search bar and search for “managed identity.”

2. Select the first option for managed identities. Once you are on the managed identities page, click the “create” button from the top navigation.

3. On the “create user-assigned managed identity” page, select the subscription, the resource group, and the location. Finally, give the managed identity a name (“vmidentity” identity in this case). Once done, click on the “review + create” button.

4. After validation has passed, click on the “create” button to provision the managed identity.

5. Go back to the virtual machine page and under settings and click on “identity.” On the identity page, click the user-assigned tab.

6. On the user-assigned tab, click on “add” from the top navigation. A pop-up will appear on the right-hand side. Select the newly-created managed identity (“vmidentity” identity in this case) and click “add.”

7. The identity will now appear under the “user-assigned managed identity” page.

8. Now go back to the storage account, and click on “access control (IAM).” Once on the access control page, click “add” from the top navigation and select “add role assignment.”

9. On the “add role assignment” page, assign the role to the newly-created user-assigned managed identity.

10. Select “managed identity” under “assign access to” and then click on “select members.” A pop-up will appear on the right-hand side. Select the newly-created user-assigned managed identity and click on the “select” button.

11. Now, click on the “review + assign” button on the main page. After validation, click on the “review + assign” button again.

12. It will take a couple of seconds for the user-assigned managed identity to be provisioned for the storage account.

Now that you’ve assigned the managed identities a role in the storage account, you can access the storage resources from the virtual machine.

Conclusion

Managed identities are helpful because of their automatic management of workload identities that authenticate to Azure Active Directory — applications obtain tokens from Azure AD without the need to manage the credentials and secrets within the app’s code. You can assign these identities roles within other resources that support Azure AD authentication to gain access to that resource. For developers and administrators, this removes the manual task of managing the credentials within the application code or workloads, reducing the possibility of any security or password leaks.