Two types of managed identities are available: system-assigned managed identities and user-assigned managed identities.<\/p>\n<\/p>\n
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.<\/p>\n<\/p>\n
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.<\/p>\n<\/p>\n
These standalone Azure resources can be assigned to multiple Azure resources, providing greater flexibility and scalability than system-assigned managed identities.<\/p>\n<\/p>\n
For example, a web app or a virtual machine can have multiple user-assigned managed identities, which multiple Azure resources can share.<\/p>\n<\/p>\n
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.<\/p>\n
Let\u2019s hypothesize we possess the following setup:<\/p>\n
So, we need to:<\/p>\n<\/p>\n
Let\u2019s start by enabling a system-assigned identity on the VM using the following command.<\/p>\n<\/p>\n
Get-AzVM -ResourceGroupName jumpbox -Name jbox01 | Update-AzVM -IdentityType SystemAssigned<\/p><\/pre>\n<\/p>\n
Adding a system-assigned managed identity to a VM<\/a><\/p>\nAdding a system-assigned managed identity to a VM<\/p>\n<\/div>\n
System-assigned managed identity can be seen on the VM\u2019s identity section<\/a><\/p>\nSystem-assigned managed identity can be seen on the VM\u2019s identity section<\/p>\n<\/div>\n
Once the system-assigned managed identity on the VM has been created, we can see it along with its objectID<\/em>, which we will use to assign roles to this identity in the following steps.<\/p>\n<\/p>\n
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<\/em> to SystemAssignedUserAssigned<\/em> to ensure we keep the system-assigned managed identity and attach the user-assigned managed identity to the VM.<\/p>\n<\/p>\n
If you forget this and set the parameter to UserAssigned<\/em>, the system-assigned managed identity will be disabled. You will end up having only a user-assigned managed identity on the VM.<\/p>\n<\/p>\n
<\/p>New-AzUserAssignedIdentity -Name UAMI-for-VM -ResourceGroupName jumpbox -Location UKSouth<\/p>
$UAMI = Get-AzUserAssignedIdentity -Name UAMI-for-VM -ResourceGroupName jumpbox<\/p>
Get-AzVM -ResourceGroupName jumpbox -Name jbox01 | Update-AzVM -IdentityType SystemAssignedUserAssigned -IdentityId $UAMI.Id<\/p>
<\/pre>\n<\/p>\n
<\/p>\n
Creating a new user-assigned managed identity<\/p>\n
<\/a><\/p>\n
<\/p>\n
User-assigned managed Identity has been added to the VM<\/p>\n
<\/a><\/p>\n
We can now go to the target resources and assign these managed identities with desired RBAC roles.<\/p>\n<\/p>\n
First, let\u2019s give the Key Vault Secrets User<\/em> role to the system-assigned managed identity on the Secret an-important-secret<\/em>. For this, we will use the following command. The ObjectID<\/em> can be obtained directly from the VM.<\/p>\n<\/p>\n
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\"<\/p><\/pre>\n<\/p>\n
System-assigned managed identity has been granted the Key Vault Secrets User role on the Key Vault<\/a><\/p>\n
Next, assign the user-created managed identity with the Storage Blob Data Reader<\/em> role on the Blob data.txt<\/em>.<\/p>\n<\/p>\n
<\/p>$UAMIObjectID = (Get-AzUserAssignedIdentity -Name uami-for-vm -ResourceGroupName jumpbox).PrincipalId<\/p>
New-AzRoleAssignment -ObjectId \"$UAMIObjectID\" -Scope \"\/subscriptions\/xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\/resourceGroups\/RBAC\/providers\/Microsoft.Storage\/storageAccounts\/rbacstracc\/\" -RoleDefinitionName \"Reader and Data Access\"<\/p>
<\/pre>\n<\/p>\n
<\/a><\/p>\n
User-assigned managed identity has been given Reader and Data Access role on the Storage Account<\/p>\n<\/p>\n
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.<\/p>\n<\/p>\n
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.<\/p>\n<\/p>\n
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.<\/p>\n<\/p>\n
Connecting to Azure from within the VM using a system-assigned managed identity<\/a><\/p>\n
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.<\/p>\n<\/p>\n
With the user-assigned managed identity, we can get the blob content.<\/p>\n<\/p>\n
Connecting to Azure from within the VM using the user-assigned managed identity<\/a><\/p>\n
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.<\/p>\n<\/p>\n