concept manage identity in category azure

This is an excerpt from Manning's book Azure Storage, Streaming, and Batch Analytics: A guide for data engineers MEAP V11. Login to get full access to this book.

Because of the available authentication modes, the Azure portal is the only supported interface for creating a Data Lake store output. An authorized user token can only be retrieved using the Azure portal. The ASA job’s managed identity can only be enabled using the Azure portal.

You should choose a name for your App registration that is distinct from the application or applications that use it. When you create a service in AAD, managed identities are also created with the same name as the Azure service they represent. When you add an App registration with the same name as the ADF service and its managed identity, it becomes difficult to select between them when assigning permissions. Managed identities are less flexible than App registrations. We’ll discuss managed identities later in the chapter.

This is an excerpt from Manning's book Learn Azure in a Month of Lunches, Second Edition. Login to get full access to this book.

The ability to use Azure Key Vault to store secrets or keys is great, but how do you access these secrets? The Azure CLI or Azure PowerShell can access the information stored in a key vault, but it’s often more convenient to allow your VMs or applications to retrieve secrets or keys directly when they need them. One way to do this is with managed identities for Azure resources, as shown in figure 15.4.

Figure 15.4 When you create a managed identity for a VM, a service principal is created in Azure Active Directory. This service principal is a special type of account that can be used for resources to authenticate themselves. Then this VM uses the Instance Metadata Service endpoint to makes requests for access to resources. The endpoint connects to Azure AD to request access tokens when the VM needs to request data from other services. When an access token is returned, it can be used to request access to Azure resources, such as a key vault.

A managed identity lets you create a special kind of account that can be used by an Azure resource, like a VM. If you’ve used a directory service such as Active Directory, a computer account is often used to identify and grant access to various network resources that a computer needs. You don’t create and use regular user accounts for this type of authentication, which improves security: you can grant a restrictive set of permissions just to a computer rather than also worrying about user permissions and shared folder access, for example.

A managed identity is like a computer account, but it’s stored in Azure Active Directory (Azure AD). The identity, called a service principal, is unique to each VM and can be used to assign permissions to other Azure resources, such as an Azure Storage account or key vault. The VM has permissions to access those resources, so you can script tasks (such as with Azure Automation, which we’ll explore in chapter 18) that require no user intervention or prompts for usernames and passwords. The VMs authenticate themselves, and the Azure platform authorizes access to their assigned resources.

You can create two types of managed identities:

System-assigned--This type of managed identity is applied directly to a resource, like a VM, and is used only by that resource. Each resource has its own unique identity when it comes to auditing or troubleshooting access. When the resource is deleted, the managed identity is deleted automatically.

User-assigned--A separate Azure resource is created and managed for the specified managed identity. This managed identity can be shared across other resources to define access. When any resources that use the identity are deleted, the managed identity remains available for use.