Create a User‐assigned Managed Identity – Keeping Data Safe and Secure

1. Log in to the Azure portal at https://portal.azure.com ➢ enter Managed Identities in the Search text box ➢ select Managed Identities ➢ select the + Create menu item ➢ enter the subscription ➢ enter the resource group ➢ enter the region ➢ enter a name (I used brainjammer) ➢ click the Review + Create button ➢ and then click Create.
2. Navigate to the Azure Storage account you created in Exercise 3.1 ➢ select Access Control (IAM) from the navigation menu ➢ select the + Add menu item ➢ select Add Role Assignment ➢ select the Contributor Role ➢ click Next ➢ select the Managed Identity radio button ➢ click the + Select Members link ➢ select User‐assigned Managed Identity from the Managed Identity drop‐down ➢ select the managed identity created in step 1 ➢ click the Select button ➢ and then click the Review + Assign button.
3. On the Access Control (IAM) blade, select the Aole assignments tab. Notice the User‐assigned Managed Identity is present in the Contributor role, as shown in Figure 8.40.

FIGURE 8.40 Creating and applying a user‐assigned managed identity

4. To show the details of the managed identity and any other identity within your subscription, use the following Azure CLI cmdlet:
   az ad sp list –display-name

Creating a user‐assigned managed identity is simple, as you just learned. Adding the identity to the Contributor role of your Azure storage account granted full access to manage all resources within the account. Any object you configure with this identity will have access to the Azure storage account and the ADLS containers within it. The Azure CLI cmdlet is helpful to identify not only user‐assigned managed identities but also system‐assigned. The use of the cmdlet using brainjammer as the value for resourceName results in the following summarized output:

The Azure CLI cmdlet might be helpful in case you have numerous Azure products with the same name and need to find the specific one to grant permissions to. The objectId attribute uniquely identifies the managed identity. You can also see which Azure product it is associated with by looking in the ARM identifier, for example, Microsoft.ManagedIdentity or Microsoft.Purview. The objectId attribute is also often rendered on the Properties blade for the Azure resource, often referred to as the managed identity object ID. In general, it is recommended to use managed identities for authentication versus any other mechanism on Azure.

At the time of writing, Azure Databricks does not support outbound managed identities. You can use a few workarounds to make this work; however, none of them is officially supported or recommended. Instead, you are confined to a user, group, or service principal, but in most cases a service principal is, in essence, the same as a managed identity. The major difference is that a managed identity is always linked to an Azure resource, and no one knows its credentials because they are managed strictly by the platform. A service principal is linked to an app registration that is created in your Azure Active Directory and is given a user ID and password. The service principal identity can be assigned to RBAC roles for granting permissions to Azure resources. This is important to call out because of the work you did in Exercise 5.4, where you needed to access data hosted on a blob storage container using the following address and the wasbs protocol:

 wasbs://<containerName>@<accountName>.blob.core.windows.net/*.parquet

This was necessary because at the time it was not possible to connect to an ADLS endpoint using a storage access key from an Apache Spark cluster. At that point you had not been exposed to Azure Key Vault, managed identities, IAM, or users, groups, and service principals. Using those authentication mechanisms allows connections to an ADLS container using the abfss protocol, as follows:

 abfss://<containerName>@<accountName>.dfs.core.windows.net/*.parquet

Now that you know a bit about these products, features, and concepts, complete Exercise 8.10, where you will use the abfss protocol to grant access to an Azure Active Directory (Azure AD) user to execute Python logic.