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.
NoteIn your component YAML, you only need the
azureClientId property if using user-assigned identity. Otherwise, you can omit this property for system-managed identity to be used by default.
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:
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.
Managed identities in Azure Container Apps
Every container app has a completely different system-managed identity, making it very unmanageable to handle the required role assignments across multiple apps.
Instead, it’s strongly recommended to use a user-assigned identity and attach this to all the apps that should load the component. Then, you should scope the component to those same apps.
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.
NoteIf the sidecar loads a component which does not specify
azureClientId, it only tries the system-assigned identity. If the component specifies the
azureClientId property, it only tries the particular user-assigned identity with that ID.
The following examples demonstrate setting up either a system-managed or user-assigned identity in an Azure KeyVault secrets component.
If you set up system-managed identity using an Azure KeyVault component, the YAML would look like the following:
- name: vaultName
In this example, the system-managed identity looks up the service identity and communicates with the
mykeyvault vault. Next, grant your system-managed identiy access to the desired service.
If you set up user-assigned identity using an Azure KeyVault component, the YAML would look like the following:
- name: vaultName
- name: azureClientId
Once you’ve set up the component YAML with the
azureClientId property, you can grant your user-assigned identity access to your service.
For component configuration in Kubernetes or AKS, refer to the Workload Identity guidance.
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
Best practice: When using user-assigned identities, make sure to scope your components to specific apps!
Next stepsRefer to Azure component specs >>
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.