Understanding Azure system assigned and user assigned identity

For most Azure resource, like, Web App, Function App, Azure VM, etc,  there is an identity property under settings section, this identity property allows developer to set a system assigned identity or user assigned identity to an azure resource (i.e secret consumer). The identity can be used by other azure resources (secret holder) to assign permissions to the secret consumers represented by the identity. Usually the secret consume is an .net core web app or a java spring web app, and secret holder is a azure keyvault, which holds the password or connection strings to database or azure storage account.

When system assigned identity is enabled, azure creates an principal ID to represent this azure resource (secret consume), each azure resource can only have one system assigned identity. Other azure resources (secret holder) can set access policies to the principal id of system assigned identity, similar to assigning permission to a role based user account, so that it enables the system assigned identity to send requests to the secure holder resources. 

For example, in Azure keyVault, under Settings' Access Policies blade, if permission is assigned to the system identity for a VM or web app, the assigned permission will show under the current access policy list. 

A typical use case involves a SPA client app, a java spring or .net core web app, datavault, and database or Azure storage account. The SPA app runs on client side and does not hold any sensitive data. The SPA app sends request to java spring or .net web app, which as a system assigned identity to allow it to access the datavault through an access policy defined in datavault, so that the web app itself does not need to save any sensitive data in its code. Also no direct trust relationships need to be configured between web app and database or storage account. The only trust relationship that needs to be configured is between the web app and datavault.

As each azure service can only has one system assigned identity, it may not be enough. In that case, multiple user assigned identities can be created. Those user assigned identities can be associated with any azure resources, and then they can be used in the same way as system assigned identity for assigning permission from other azure resources.

The system assigned identity can be enabled from azure portal or az portal shell. The below command creates a system identity for a azure web app 

az webapp identity assign --name yourWebappName --resource-group yourResourceGroupName

The output includes the principal identity as below

{

  "principalId": "1c36874b-3a68-47b5-88ed-4b1ef9ee45b7",

  "tenantId": "7fe7fa7d-cac4-43e5-8f35-eec8db5a662f",

  "type": "SystemAssigned",

  "userAssignedIdentities": null

}

In order to get permission to azure resource (like a key vault), you can set the permission from the azure resource (secret holder) as below

az keyvault set-policy --name haiquankeyvault --object-id 1c36874b-3a68-47b5-88ed-4b1ef9ee45b7 --secret-permissions get list

After the command, the access policy of the keyvault resource will include a new item for allowed permission assigned to the web app.

One particular use case for Azure managed identity is for Azure virtual machine, as once the permission is assigned to the VM's system identity, then any apps or services running on this Virtual machine can transparently get this VM identity's permission to access the assigned resources without providing any credentials or access key information.

The below command creates a system assigned identity for an Azure virtual machine.

az vm identity assign --name myVM --resource-group myResourceGroup

The output of the command is the identity of the vm as below:

{

  "systemAssignedIdentity": "d5b1bb44-a5b5-4eeb-9c68-920a385d310c",

  "userAssignedIdentities": {}

}

The identity created by the above commands can represent the VM to assign permission to this VM identity. The below code assigning Azure keyvault permission to the system assigned identity created before.

az keyvault set-policy --name haiquankeyvault --object-id d5b1bb44-a5b5-4eeb-9c68-920a385d310c --secret-permissions backup, delete, get, list, purge, recover, restore, set

The below code shows how a .net core apps running in the VM can use SecretClient and DefaultAzureCredential instance s to get the access to the keyvault without providing any credentials.

        static void Main(string[] args)

        {

            string secretName = "mySecret";

            string keyVaultName = "haiquankeyvault";

            var kvUri = "https://haiquankeyvault.vault.azure.net";

            var client = new SecretClient(new Uri(kvUri), new DefaultAzureCredential());

            Console.Write("Input the value of your secret > ");

            string secretValue = Console.ReadLine();

            client.SetSecret(secretName, secretValue);

            Console.WriteLine(" done.");

}