Azure Container Apps Environment : DAPR Key Vault Secret Store Global Managed Identity

Question

Azure Container Apps Environment : DAPR Key Vault Secret Store Global Managed Identity

Amit-J 341

Hi,

I created key vault secret store DAPR component in container apps environment by following the article - https://learn.microsoft.com/en-us/azure/container-apps/dapr-component-connect-services#azure-key-vault-secret-stores

so, i have issues regarding the Managed Identity to fetch secret from key vault. I have 10 apps deployed on environment and if I give the identity of 1 app to the store, only that app works.. and other 9 apps "daprd" sidecar fails to initialize with error, "Unable to load proper Managed Identity".

If I omit the client id field and dont provide any managed identity to the secret store. then no app works.

However, if I just add the scope in the secret store, with any gibberish string, all the app starst working.. it seems when the scope is provided and no cleint id, all the apps use their own MIs to access key vault.. i know its a bug.

I also tried creating a new MI and attach to the container app environemnt, and provide that cleint id to the secret store, it doesnt work for any app..

so the only solution i can think of is...to create a shared common MI and attach it to all the 10 apps and mention that client id in secret store.. yes this will mean that most of my apps might end up multiple MIs attached to themselves..

is there a proper solution, where i can create only 1 kv secret store and use it globally for all apps in the same container app environment ????

Khadeer Ali 5,065 Reputation points Microsoft External Staff Moderator

2025-05-06T15:45:09.4966667+00:00
@Amit-J ,

Thank you for the detailed explanation of your scenario.

Based on the current behavior and Microsoft's documentation regarding Dapr secret stores with Azure Key Vault, there is an approach you may consider testing that could help streamline access for all your Container Apps:

If you would like each app in your Azure Container Apps environment to access the same Key Vault secret store using their own system-assigned managed identity, you can configure the Dapr component without the azureClientId and instead include a dummy scope field (e.g., scope: dummy). This triggers the identity resolution logic in Dapr, allowing each app's sidecar to authenticate using its system-assigned identity.

Here’s an example of the configuration:

- name: vaultName value: <your-keyvault-name> - name: scope value: dummy

Please ensure that each Container App's system-assigned managed identity has the appropriate permissions (such as "Key Vault Secrets User") on the Key Vault.

While this pattern has been observed to work in similar scenarios, I would recommend testing it in your non-production environment first to confirm it behaves as expected in your setup. This approach aligns with documented behavior, but results may vary slightly depending on your specific configuration.
Amit-J 341 Reputation points

2025-05-07T10:26:23.8366667+00:00

I am using user assigned managed identity.

And is there any documentation from Microsoft which can explain this dummy scope behaviour ? Because it does not work actually... my sidecar daprd container starts but it does not work.. I think daprd is initializing successfully but not able to read secret from kv store.. because dummy scope means none of the apps can use kv-store component now..

So, I would really love to know what is the recommendation from Microsoft on implementing Single kv secret store for all apps using a common MI ?
Khadeer Ali 5,065 Reputation points Microsoft External Staff Moderator

2025-05-07T15:32:33.3133333+00:00

@Amit-J ,

Thank you again for the clarification regarding the use of user-assigned managed identities (UAMI).

The behavior you observed—where providing a dummy scope value without a clientId allows apps to access the Key Vault—has been noted in scenarios using system-assigned managed identities (SAMI). In those cases, Dapr internally falls back to using each app’s system identity when no clientId is specified, and the presence of a scope key (even with a dummy value) appears to trigger this resolution.

However, this pattern is not officially documented or guaranteed to work with user-assigned managed identities (UAMI), where the azureClientId field is a required configuration. Without it, Dapr cannot determine which identity to use, which is likely why you're seeing errors when using UAMI without specifying a client ID.

I’ll check with additional findings or recommendations shortly.

Please let me know if you have any preferences or constraints regarding how the shared UAMI is managed or assigned.
Amit-J 341 Reputation points

2025-05-08T06:53:54.5233333+00:00

i have not tested dummy scope with System Assigned Managed Identity because I am using User Assigned Managed Identities for my apps and it does not work with dummy scope.

I think the only solution here would be to create a shared MI and assign it to all the apps and mention the client id in the kv store component.

Arko 2,605 Microsoft External Staff Moderator

Hello Amit-J,

If you don't have any issues using system assigned identity, then I can show you how to configure a Dapr Key Vault secret store in Azure Container Apps that works across all apps in the same environment without needing a shared UAMI or clientId

Create the Key Vault with RBAC Enabled


az keyvault create \

  --name arkorg-kv \

  --resource-group arkorg \

  --location centralindia \

  --enable-rbac-authorization true

Add a secret


az keyvault secret set \

  --vault-name arkorg-kv \

  --name testsecret \

  --value "supersecretvalue"

Create Container App Environment


az containerapp env create \

  --name dapr-env \

  --resource-group arkorg \

  --location centralindia

Deploy Dapr Secret Store Component Using ARM Template

Use the following dapr-secret-component.json


{

  "$schema": "https://schema.management.azure.com/schemas/2019-08-01/deploymentTemplate.json#",

  "contentVersion": "1.0.0.0",

  "resources": [

    {

      "type": "Microsoft.App/managedEnvironments/daprComponents",

      "apiVersion": "2023-05-01",

      "name": "dapr-env/kv-secretstore",

      "properties": {

        "componentType": "secretstores.azure.keyvault",

        "version": "v1",

        "metadata": [

          { "name": "vaultName", "value": "arkorg-kv" },

          { "name": "scope", "value": "dummy" }

        ]

      }

    }

  ]

}

Deploy it


az deployment group create \

  --resource-group arkorg \

  --template-file dapr-secret-component.json

aca2

Deploy a Container App with System-Assigned Identity


az containerapp create \

  --name app-a \

  --resource-group arkorg \

  --environment dapr-env \

  --image mcr.microsoft.com/k8se/quickstart:latest \

  --target-port 80 \

  --ingress external \

  --enable-dapr \

  --dapr-app-id app-a \

  --system-assigned

aca3

Grant Key Vault Access to the App


az role assignment create \

  --assignee <app-principal-id> \

  --role "Key Vault Secrets User" \

  --scope $(az keyvault show --name arkorg-kv --resource-group arkorg --query id -o tsv)

aca4

Confirm Secret Access via Dapr Sidecar


az containerapp exec \

  --name app-a \

  --resource-group arkorg \

  --command "/bin/sh"

Inside container do a


curl http://localhost:3500/v1.0/secrets/kv-secretstore/testsecret

You should see the secret

aca5

This setup avoids the need for shared UAMI and azureClientId, and is cleanly managed via system-assigned identities with RBAC. Dapr sidecars in all apps resolve their own identity using the scope: dummy pattern.

Hope this was helpful for you.

Arko 2,605 Reputation points Microsoft External Staff Moderator

2025-05-15T04:30:30.05+00:00

Following up on this Amit. Hope I was able to help you here.
Arko 2,605 Reputation points Microsoft External Staff Moderator

2025-05-17T03:34:28.1633333+00:00

Hope your issue is resolved Amit

Your answer

Khadeer Ali 5,065 Reputation points Microsoft External Staff Moderator

2025-05-06T15:45:09.4966667+00:00

@Amit-J ,

Thank you for the detailed explanation of your scenario.

Based on the current behavior and Microsoft's documentation regarding Dapr secret stores with Azure Key Vault, there is an approach you may consider testing that could help streamline access for all your Container Apps:

If you would like each app in your Azure Container Apps environment to access the same Key Vault secret store using their own system-assigned managed identity, you can configure the Dapr component without the azureClientId and instead include a dummy scope field (e.g., scope: dummy). This triggers the identity resolution logic in Dapr, allowing each app's sidecar to authenticate using its system-assigned identity.

Here’s an example of the configuration:

- name: vaultName value: <your-keyvault-name> - name: scope value: dummy

Please ensure that each Container App's system-assigned managed identity has the appropriate permissions (such as "Key Vault Secrets User") on the Key Vault.

While this pattern has been observed to work in similar scenarios, I would recommend testing it in your non-production environment first to confirm it behaves as expected in your setup. This approach aligns with documented behavior, but results may vary slightly depending on your specific configuration.
Amit-J 341 Reputation points

2025-05-07T10:26:23.8366667+00:00

I am using user assigned managed identity.

And is there any documentation from Microsoft which can explain this dummy scope behaviour ? Because it does not work actually... my sidecar daprd container starts but it does not work.. I think daprd is initializing successfully but not able to read secret from kv store.. because dummy scope means none of the apps can use kv-store component now..

So, I would really love to know what is the recommendation from Microsoft on implementing Single kv secret store for all apps using a common MI ?
Khadeer Ali 5,065 Reputation points Microsoft External Staff Moderator

2025-05-07T15:32:33.3133333+00:00

@Amit-J ,

Thank you again for the clarification regarding the use of user-assigned managed identities (UAMI).

The behavior you observed—where providing a dummy scope value without a clientId allows apps to access the Key Vault—has been noted in scenarios using system-assigned managed identities (SAMI). In those cases, Dapr internally falls back to using each app’s system identity when no clientId is specified, and the presence of a scope key (even with a dummy value) appears to trigger this resolution.

However, this pattern is not officially documented or guaranteed to work with user-assigned managed identities (UAMI), where the azureClientId field is a required configuration. Without it, Dapr cannot determine which identity to use, which is likely why you're seeing errors when using UAMI without specifying a client ID.

I’ll check with additional findings or recommendations shortly.

Please let me know if you have any preferences or constraints regarding how the shared UAMI is managed or assigned.
Amit-J 341 Reputation points

2025-05-08T06:53:54.5233333+00:00

i have not tested dummy scope with System Assigned Managed Identity because I am using User Assigned Managed Identities for my apps and it does not work with dummy scope.

I think the only solution here would be to create a shared MI and assign it to all the apps and mention the client id in the kv store component.
Arko 2,605 Reputation points Microsoft External Staff Moderator

2025-05-15T04:30:30.05+00:00

Following up on this Amit. Hope I was able to help you here.
Arko 2,605 Reputation points Microsoft External Staff Moderator

2025-05-17T03:34:28.1633333+00:00

Hope your issue is resolved Amit

Share via

Azure Container Apps Environment : DAPR Key Vault Secret Store Global Managed Identity

Your answer