How to: Use managed identities

Using managed identities, authentication happens automatically by virtue of your application running on top of an Azure service that has either a system-managed or a user-assigned identity.

To get started, you need to enable a managed identity as a service option/functionality in various Azure services, independent of Dapr. Enabling this creates an identity (or application) under the hood for Microsoft Entra ID (previously Azure Active Directory ID) purposes.

Your Dapr services can then leverage that identity to authenticate with Microsoft Entra ID, transparently and without you having to specify any credentials.

In this guide, you learn how to:

• Grant your identity to the Azure service you’re using via official Azure documentation
• Set up either a system-managed or user-assigned identity in your component

That’s about all there is to it.

Grant access to the service

Set the requisite Microsoft Entra ID role assignments or custom permissions to your system-managed or user-assigned identity for a particular Azure resource (as identified by the resource scope).

You can set up a managed identity to a new or existing Azure resource. The instructions depend on the service use. Check the following official documentation for the most appropriate instructions:

• Azure Kubernetes Service (AKS)
• Azure Container Apps (ACA)
• Azure App Service (including Azure Web Apps and Azure Functions)
• Azure Virtual Machines (VM)
• Azure Virtual Machines Scale Sets (VMSS)
• Azure Container Instance (ACI)

After assigning a system-managed identity to your Azure resource, you’ll have credentials like the following:

{
    "principalId": "<object-id>",
    "tenantId": "<tenant-id>",
    "type": "SystemAssigned",
    "userAssignedIdentities": null
}

From the returned values, take note of the principalId value, which is the Service Principal ID created for your identity. Use that to grant access permissions for your Azure resources component to access the identity.

Set up identities in your component

By default, Dapr Azure components look up the system-managed identity of the environment they run in and authenticate as that. Generally, for a given component, there are no required properties to use system-managed identity other than the service name, storage account name, and any other properites required by the Azure service (listed in the documentation).

For user-assigned idenitities, in addition to the basic properties required by the service you’re using, you need to specify the azureClientId (user-assigned identity ID) in the component. Make sure the user-assigned identity is attached to the Azure service Dapr is running on, or else you won’t be able to use that identity.

The following examples demonstrate setting up either a system-managed or user-assigned identity in an Azure KeyVault secrets component.

• System-managed
• User-assigned
• Kubernetes

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: mykeyvault

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: mykeyvault
  - name: azureClientId
    value: someAzureIdentityClientIDHere

Troubleshooting

If you receive an error or your managed identity doesn’t work as expected, check if the following items are true:

• The system-managed identity or user-assigned identity don’t have the required permissions on the target resource.

• The user-assigned identity isn’t attached to the Azure service (container app or pod) from which you’re loading the component. This can especially happen if:

  • You have an unscoped component (a component loaded by all container apps in an environment, or all deployments in your AKS cluster).
  • You attached the user-assigned identity to only one container app or one deployment in AKS (using Azure Workload Identity).

  In this scenario, since the identity isn’t attached to every other container app or deployment in AKS, the component referencing the user-assigned identity via azureClientId fails.

Best practice: When using user-assigned identities, make sure to scope your components to specific apps!

Next steps