Integrations with Azure

• 1: Authenticate to Azure
• 1.1: Authenticating to Azure
• 1.2: How to: Generate a new Microsoft Entra ID application and Service Principal
• 1.3: How to: Use managed identities
• 2: Dapr integration policies for Azure API Management
• 3: Dapr extension for Azure Functions runtime
• 4: Dapr extension for Azure Kubernetes Service (AKS)

1 - Authenticate to Azure

1.1 - Authenticating to Azure

Most Azure components for Dapr support authenticating with Microsoft Entra ID. Thanks to this:

• Administrators can leverage all the benefits of fine-tuned permissions with Azure Role-Based Access Control (RBAC).
• Applications running on Azure services such as Azure Container Apps, Azure Kubernetes Service, Azure VMs, or any other Azure platform services can leverage Managed Identities (MI) and Workload Identity. These offer the ability to authenticate your applications without having to manage sensitive credentials.

About authentication with Microsoft Entra ID

Microsoft Entra ID is Azure’s identity and access management (IAM) solution, which is used to authenticate and authorize users and services.

Microsoft Entra ID is built on top of open standards such OAuth 2.0, which allows services (applications) to obtain access tokens to make requests to Azure services, including Azure Storage, Azure Service Bus, Azure Key Vault, Azure Cosmos DB, Azure Database for Postgres, Azure SQL, etc.

In Azure terminology, an application is also called a “Service Principal”.

Some Azure components offer alternative authentication methods, such as systems based on “shared keys” or “access tokens”. Although these are valid and supported by Dapr, you should authenticate your Dapr components using Microsoft Entra ID whenever possible to take advantage of many benefits, including:

• Managed Identities and Workload Identity
• Role-Based Access Control
• Auditing
• (Optional) Authentication using certificates

Managed Identities and Workload Identity

With Managed Identities (MI), your application can authenticate with Microsoft Entra ID and obtain an access token to make requests to Azure services. When your application is running on a supported Azure service (such as Azure VMs, Azure Container Apps, Azure Web Apps, etc), an identity for your application can be assigned at the infrastructure level.

Once using MI, your code doesn’t have to deal with credentials, which:

• Removes the challenge of managing credentials safely
• Allows greater separation of concerns between development and operations teams
• Reduces the number of people with access to credentials
• Simplifies operational aspects–especially when multiple environments are used

Applications running on Azure Kubernetes Service can similarly leverage Workload Identity to automatically provide an identity to individual pods.

Role-Based Access Control

When using Azure Role-Based Access Control (RBAC) with supported services, permissions given to an application can be fine-tuned. For example, you can restrict access to a subset of data or make the access read-only.

Auditing

Using Microsoft Entra ID provides an improved auditing experience for access. Tenant administrators can consult audit logs to track authentication requests.

(Optional) Authentication using certificates

While Microsoft Entra ID allows you to use MI, you still have the option to authenticate using certificates.

Support for other Azure environments

By default, Dapr components are configured to interact with Azure resources in the “public cloud”. If your application is deployed to another cloud, such as Azure China or Azure Government (“sovereign clouds”), you can enable that for supported components by setting the azureEnvironment metadata property to one of the supported values:

• Azure public cloud (default): "AzurePublicCloud"
• Azure China: "AzureChinaCloud"
• Azure Government: "AzureUSGovernmentCloud"

Support for sovereign clouds is experimental.

Credentials metadata fields

To authenticate with Microsoft Entra ID, you will need to add the following credentials as values in the metadata for your Dapr component.

Metadata options

Depending on how you’ve passed credentials to your Dapr services, you have multiple metadata options.

• Using client credentials
• Using a certificate
• Using Managed Identities (MI)
• Using Workload Identity on AKS
• Using Azure CLI credentials (development-only)

Authenticating using client credentials

When running on Kubernetes, you can also use references to Kubernetes secrets for any or all of the values above.

Authenticating using a certificate

When running on Kubernetes, you can also use references to Kubernetes secrets for any or all of the values above.

Authenticating with Managed Identities (MI)

Using Managed Identities, the azureClientId field is generally recommended. The field is optional when using a system-assigned identity, but may be required when using user-assigned identities.

Authenticating with Workload Identity on AKS

When running on Azure Kubernetes Service (AKS), you can authenticate components using Workload Identity. Refer to the Azure AKS documentation on enabling Workload Identity for your Kubernetes resources.

Authenticating using Azure CLI credentials (development-only)

Important: This authentication method is recommended for development only.

This authentication method can be useful while developing on a local machine. You will need:

• The Azure CLI installed
• Have successfully authenticated using the az login command

When Dapr is running on a host where there are credentials available for the Azure CLI, components can use those to authenticate automatically if no other authentication method is configuration.

Using this authentication method does not require setting any metadata option.

Example usage in a Dapr component

In this example, you will set up an Azure Key Vault secret store component that uses Microsoft Entra ID to authenticate.

• Self-Hosted
• Kubernetes

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
  namespace: default
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: "[your_keyvault_name]"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureClientSecret
    value : "[your_client_secret]"

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
  namespace: default
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: "[your_keyvault_name]"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureCertificateFile
    value : "[pfx_certificate_file_fully_qualified_local_path]"

Next steps

References

• Microsoft Entra ID app credential: Azure CLI reference
• Azure Managed Service Identity (MSI) overview
• Secrets building block
• How-To: Retrieve a secret
• How-To: Reference secrets in Dapr components
• Secrets API reference

1.2 - How to: Generate a new Microsoft Entra ID application and Service Principal

Prerequisites

• An Azure subscription
• Azure CLI
• jq
• OpenSSL (included by default on all Linux and macOS systems, as well as on WSL)
• Make sure you’re using a bash or zsh shell

Log into Azure using the Azure CLI

In a new terminal, run the following command:

az login
az account set -s [your subscription id]

Create an Microsoft Entra ID application

Create the Microsoft Entra ID application with:

# Friendly name for the application / Service Principal
APP_NAME="dapr-application"

# Create the app
APP_ID=$(az ad app create --display-name "${APP_NAME}"  | jq -r .appId)

Select how you’d prefer to pass credentials.

• Client secret
• PFX certificate

az ad app credential reset \
  --id "${APP_ID}" \
  --years 2

{
  "appId": "<your-app-id>",
  "password": "<your-password>",
  "tenant": "<your-azure-tenant>"
}

az ad app credential reset \
  --id "${APP_ID}" \
  --create-cert

{
  "appId": "<your-app-id>",
  "fileWithCertAndPrivateKey": "<file-path>",
  "password": null,
  "tenant": "<your-azure-tenant>"
}

Create a Service Principal

Once you have created an Microsoft Entra ID application, create a Service Principal for that application. With this Service Principal, you can grant it access to Azure resources.

To create the Service Principal, run the following command:

SERVICE_PRINCIPAL_ID=$(az ad sp create \
  --id "${APP_ID}" \
  | jq -r .id)
echo "Service Principal ID: ${SERVICE_PRINCIPAL_ID}"

Expected output:

Service Principal ID: 1d0ccf05-5427-4b5e-8eb4-005ac5f9f163

The returned value above is the Service Principal ID, which is different from the Microsoft Entra ID application ID (client ID). The Service Principal ID is defined within an Azure tenant and used to grant access to Azure resources to an application
You’ll use the Service Principal ID to grant permissions to an application to access Azure resources.

Meanwhile, the client ID is used by your application to authenticate. You’ll use the client ID in Dapr manifests to configure authentication with Azure services.

Keep in mind that the Service Principal that was just created does not have access to any Azure resource by default. Access will need to be granted to each resource as needed, as documented in the docs for the components.

Next steps

1.3 - 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

2 - Dapr integration policies for Azure API Management

Azure API Management is a way to create consistent and modern API gateways for back-end services, including those built with Dapr. You can enable Dapr support in self-hosted API Management gateways to allow them to:

• Forward requests to Dapr services
• Send messages to Dapr Pub/Sub topics
• Trigger Dapr output bindings

Try out the Dapr & Azure API Management Integration sample.

3 - Dapr extension for Azure Functions runtime

Dapr integrates with the Azure Functions runtime via an extension that lets a function seamlessly interact with Dapr.

• Azure Functions provides an event-driven programming model.
• Dapr provides cloud-native building blocks.

The extension combines the two for serverless and event-driven apps.

4 - Dapr extension for Azure Kubernetes Service (AKS)

The recommended approach for installing Dapr on AKS is to use the AKS Dapr extension. The extension offers:

• Support for all native Dapr configuration capabilities through command-line arguments via the Azure CLI
• The option of opting into automatic minor version upgrades of the Dapr runtime

Prerequisites for using the Dapr extension for AKS:

• An Azure subscription
• The latest version of the Azure CLI
• An existing AKS cluster
• The Azure Kubernetes Service RBAC Admin role