Two types of managed identities are available: system-assigned managed identities and user-assigned managed identities.
System-assigned managed identities
These identities are specific to an Azure resource, such as a virtual machine or a web app. Therefore, their lifecycle is closely tied to that resource. A system-assigned managed identity is automatically deleted if the resource is removed.
These identities are only used by the corresponding Azure resource to request tokens from Microsoft Entra ID, meaning they cannot be used for more than one resource.
User-assigned managed identities
These standalone Azure resources can be assigned to multiple Azure resources, providing greater flexibility and scalability than system-assigned managed identities.
For example, a web app or a virtual machine can have multiple user-assigned managed identities, which multiple Azure resources can share.
Initially, one has to establish a managed identity within Azure. This identity is then connected with the relevant Azure resource. Subsequently, the identity has to be allowed to access the required resource. We’ll illustrate this with a particular example in the subsequent discussion.
Instance of Managed identities
Let’s hypothesize we possess the following setup:
- A VM termed jbox01 that holds both a system-assigned managed identity and a user-assigned managed identity
- A storage account termed rbacstracc possessing a blob named data.txt
- A Key Vault called certkv01 containing a secret referred to as an-important-secret.
So, we need to:
- Assign the Key Vault Secret User role to the system-assigned managed identity of the VM on the Key Vault Secret
- Assign the Reader and Data Access role to the user-assigned managed identity of the VM on the storage account
- Try to access the Key Vault, read the secret using each identity separately, and observe the outcome
- Try to access the Storage Account, read the blob content using each identity separately, and observe the outcome.
Let’s start by enabling a system-assigned identity on the VM using the following command.
Get-AzVM -ResourceGroupName jumpbox -Name jbox01 | Update-AzVM -IdentityType SystemAssigned
Adding a system-assigned managed identity to a VM
System-assigned managed identity can be seen on the VM’s identity section
Once the system-assigned managed identity on the VM has been created, we can see it along with its objectID, which we will use to assign roles to this identity in the following steps.
Now, create a new user-assigned managed identity and assign it to the VM. So, the VM will have both system-assigned and user-assigned managed identities at the same time. It is important to note that we will set the IdentityType to SystemAssignedUserAssigned to ensure we keep the system-assigned managed identity and attach the user-assigned managed identity to the VM.
If you forget this and set the parameter to UserAssigned, the system-assigned managed identity will be disabled. You will end up having only a user-assigned managed identity on the VM.
New-AzUserAssignedIdentity -Name UAMI-for-VM -ResourceGroupName jumpbox -Location UKSouth
$UAMI = Get-AzUserAssignedIdentity -Name UAMI-for-VM -ResourceGroupName jumpbox
Get-AzVM -ResourceGroupName jumpbox -Name jbox01 | Update-AzVM -IdentityType SystemAssignedUserAssigned -IdentityId $UAMI.Id
Creating a new user-assigned managed identity
User-assigned managed Identity has been added to the VM
We can now go to the target resources and assign these managed identities with desired RBAC roles.
First, let’s give the Key Vault Secrets User role to the system-assigned managed identity on the Secret an-important-secret. For this, we will use the following command. The ObjectID can be obtained directly from the VM.
New-AzRoleAssignment -ObjectId "35942614-984a-4067-8552-b806e2211124" -Scope "/subscriptions/xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/certs/providers/Microsoft.KeyVault/vaults/certkv01/secrets/an-important-secret" -RoleDefinitionName "Key Vault Secrets User"
System-assigned managed identity has been granted the Key Vault Secrets User role on the Key Vault
Next, assign the user-created managed identity with the Storage Blob Data Reader role on the Blob data.txt.
$UAMIObjectID = (Get-AzUserAssignedIdentity -Name uami-for-vm -ResourceGroupName jumpbox).PrincipalId
New-AzRoleAssignment -ObjectId "$UAMIObjectID" -Scope "/subscriptions/xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/RBAC/providers/Microsoft.Storage/storageAccounts/rbacstracc/" -RoleDefinitionName "Reader and Data Access"
User-assigned managed identity has been given Reader and Data Access role on the Storage Account
Firstly, let’s examine how we can connect to Azure from within the VM using the system-assigned managed identity and see what we can access. If you have both a system-assigned managed identity and a user-assigned managed identity enabled on a resource and attempt to connect to Azure using the Connect-AzAccount -Identity command, the system-assigned managed identity will be the default choice.
If you possess solely a user-allotted managed identity, it is effectually chosen. In scenarios where you have multiple user-assigned managed identities, designate the identity you wish to employ when establishing connection with Azure.
Reflecting upon the example provided below, we observed that connection to Azure was achieved using a system-distributed managed identity, accessing the key vault secret. This could be attributed to the fact that the identity had been given the privilege of accessing the Key Vault Secret.
Connecting to Azure from within the VM using a system-assigned managed identity
In a subsequent endeavor, attempt establishing connection making use of the user-assigned managed identity to discern the resources which are accessible. It is important to note on this occasion, the client ID of the user-assigned managed identity was employed for Azure connection.
With the user-assigned managed identity, we can get the blob content.
Connecting to Azure from within the VM using the user-assigned managed identity
However, we cannot get the Key Vault Secret with the same user identity as the user-assigned managed identity does not have access to the Key Vault.
User-assigned managed identity does not have access to the Key Vault Secret
Similarly, suppose we return to the system-assigned managed identity and try to access the storage account blob. In that case, it will not be permitted as the system-assigned managed identity does not have permissions on the storage account.
Subscribe to 4sysops newsletter!
System-assigned managed identity does not have access to the Storage Account