You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For Azure-hosted services, Dapr can use [the managed identity of the scoped container apps][aca-managed-id] to authenticate to the backend service provider. When using managed identity, you don't need to include secret information in a component manifest. Using managed identity is preferred as it eliminates storage of sensitive input in components and doesn't require managing a secret store.
24
+
25
+
> [!NOTE]
26
+
> The `azureClientId` metadata field (the client ID of the managed identity) is **required** for any component authenticating with user-assigned managed identity.
27
+
28
+
### Using a Dapr secret store component reference
29
+
30
+
When you create Dapr components for non-Entra ID enabled services, certain metadata fields require sensitive input values. The recommended approach for retrieving these secrets is to reference an existing Dapr secret store component that securely accesses secret information.
31
+
32
+
To set up a reference:
33
+
34
+
1.[Create a Dapr secret store component using the Azure Container Apps schema.](#creating-a-dapr-secret-store-component) The component type for all supported Dapr secret stores begins with `secretstores.`.
35
+
1.[Create extra components (as needed) which reference the Dapr secret store component](#referencing-dapr-secret-store-components) you created to retrieve the sensitive metadata input.
36
+
37
+
#### Creating a Dapr secret store component
38
+
39
+
When creating a secret store component in Azure Container Apps, you can provide sensitive information in the metadata section in either of the following ways:
40
+
41
+
-[For an **Azure Key Vault secret store**,](#using-managed-identity) use managed identity to establish the connection.
42
+
-[For **non-Azure secret stores**,](#platform-managed-kubernetes-secrets) use platform-managed Kubernetes secrets that are defined directly as part of the component manifest.
43
+
44
+
##### Azure Key Vault secret stores
45
+
46
+
The following component showcases the simplest possible secret store configuration using an Azure Key Vault secret store. In this example, publisher and subscriber applications are configured to both have a system or user-assigned managed identity with appropriate permissions on the Azure Key Vault instance.
47
+
48
+
```yaml
49
+
componentType: secretstores.azure.keyvault
50
+
version: v1
51
+
metadata:
52
+
- name: vaultName
53
+
value: [your_keyvault_name]
54
+
- name: azureEnvironment
55
+
value: "AZUREPUBLICCLOUD"
56
+
- name: azureClientId # Only required for authenticating user-assigned managed identity
57
+
value: [your_managed_identity_client_id]
58
+
scopes:
59
+
- publisher-app
60
+
- subscriber-app
61
+
```
62
+
63
+
##### Platform-managed Kubernetes secrets
64
+
65
+
Kubernetes secrets, Local environment variables, and Local file Dapr secret stores aren't supported in Azure Container Apps. As an alternative for the upstream Dapr default Kubernetes secret store, Azure Container Apps provides a platform-managed approach for creating and leveraging Kubernetes secrets.
66
+
67
+
This component configuration defines the sensitive value as a secret parameter that can be referenced from the metadata section. This approach can be used to connect to non-Azure services or in dev/test scenarios for quickly deploying components via the CLI without setting up a secret store or managed identity.
68
+
69
+
```yaml
70
+
componentType: secretstores.azure.keyvault
71
+
version: v1
72
+
metadata:
73
+
- name: vaultName
74
+
value: [your_keyvault_name]
75
+
- name: azureEnvironment
76
+
value: "AZUREPUBLICCLOUD"
77
+
- name: azureTenantId
78
+
value: "[your_tenant_id]"
79
+
- name: azureClientId
80
+
value: "[your_client_id]"
81
+
- name: azureClientSecret
82
+
secretRef: azClientSecret
83
+
secrets:
84
+
- name: azClientSecret
85
+
value: "[your_client_secret]"
86
+
scopes:
87
+
- publisher-app
88
+
- subscriber-app
89
+
```
90
+
91
+
#### Referencing Dapr secret store components
92
+
93
+
Once you [create a Dapr secret store using one of the previous approaches](#creating-a-dapr-secret-store-component), you can reference that secret store from other Dapr components in the same environment. The following example demonstrates using Entra ID authentication.
For Azure-hosted services, Dapr can use [the managed identity of the scoped container apps][aca-managed-id] to authenticate to the backend service provider. When using managed identity, you don't need to include secret information in a component manifest. Using managed identity is preferred as it eliminates storage of sensitive input in components and doesn't require managing a secret store.
88
-
89
-
> [!NOTE]
90
-
> The `azureClientId` metadata field (the client ID of the managed identity) is **required** for any component authenticating with user-assigned managed identity.
91
-
92
-
### Using a Dapr secret store component reference
93
-
94
-
When you create Dapr components for non-Entra ID enabled services, certain metadata fields require sensitive input values. The recommended approach for retrieving these secrets is to reference an existing Dapr secret store component that securely accesses secret information.
95
-
96
-
To set up a reference:
97
-
98
-
1. [Create a Dapr secret store component using the Azure Container Apps schema.](#creating-a-dapr-secret-store-component) The component type for all supported Dapr secret stores begins with `secretstores.`.
99
-
1. [Create extra components (as needed) which reference the Dapr secret store component](#referencing-dapr-secret-store-components) you created to retrieve the sensitive metadata input.
100
-
101
-
#### Creating a Dapr secret store component
102
-
103
-
When creating a secret store component in Azure Container Apps, you can provide sensitive information in the metadata section in either of the following ways:
104
-
105
-
- [For an **Azure Key Vault secret store**,](#using-managed-identity) use managed identity to establish the connection.
106
-
- [For **non-Azure secret stores**,](#platform-managed-kubernetes-secrets) use platform-managed Kubernetes secrets that are defined directly as part of the component manifest.
107
-
108
-
##### Azure Key Vault secret stores
109
-
110
-
The following component showcases the simplest possible secret store configuration using an Azure Key Vault secret store. In this example, publisher and subscriber applications are configured to both have a system or user-assigned managed identity with appropriate permissions on the Azure Key Vault instance.
111
-
112
-
```yaml
113
-
componentType: secretstores.azure.keyvault
114
-
version: v1
115
-
metadata:
116
-
- name: vaultName
117
-
value: [your_keyvault_name]
118
-
- name: azureEnvironment
119
-
value: "AZUREPUBLICCLOUD"
120
-
- name: azureClientId # Only required for authenticating user-assigned managed identity
121
-
value: [your_managed_identity_client_id]
122
-
scopes:
123
-
- publisher-app
124
-
- subscriber-app
125
-
```
126
-
127
-
##### Platform-managed Kubernetes secrets
128
-
129
-
Kubernetes secrets, Local environment variables, and Local file Dapr secret stores aren't supported in Azure Container Apps. As an alternative for the upstream Dapr default Kubernetes secret store, Azure Container Apps provides a platform-managed approach for creating and leveraging Kubernetes secrets.
130
-
131
-
This component configuration defines the sensitive value as a secret parameter that can be referenced from the metadata section. This approach can be used to connect to non-Azure services or in dev/test scenarios for quickly deploying components via the CLI without setting up a secret store or managed identity.
132
-
133
-
```yaml
134
-
componentType: secretstores.azure.keyvault
135
-
version: v1
136
-
metadata:
137
-
- name: vaultName
138
-
value: [your_keyvault_name]
139
-
- name: azureEnvironment
140
-
value: "AZUREPUBLICCLOUD"
141
-
- name: azureTenantId
142
-
value: "[your_tenant_id]"
143
-
- name: azureClientId
144
-
value: "[your_client_id]"
145
-
- name: azureClientSecret
146
-
secretRef: azClientSecret
147
-
secrets:
148
-
- name: azClientSecret
149
-
value: "[your_client_secret]"
150
-
scopes:
151
-
- publisher-app
152
-
- subscriber-app
153
-
```
154
-
155
-
#### Referencing Dapr secret store components
156
-
157
-
Once you [create a Dapr secret store using one of the previous approaches](#creating-a-dapr-secret-store-component), you can reference that secret store from other Dapr components in the same environment. The following example demonstrates using Entra ID authentication.
Copy file name to clipboardExpand all lines: articles/container-apps/enable-dapr.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,15 @@
1
1
---
2
-
title: Enable Dapr on your container app
2
+
title: Enable Dapr on an existing container app
3
3
description: Learn more about enabling Dapr on your Azure Container App service to develop applications.
4
4
ms.author: hannahhunter
5
5
author: hhunter-ms
6
6
ms.service: azure-container-apps
7
7
ms.custom: build-2023, devx-track-bicep
8
8
ms.topic: conceptual
9
-
ms.date: 12/18/2023
9
+
ms.date: 11/25/2024
10
10
---
11
11
12
-
# Enable Dapr on your container app
12
+
# Enable Dapr on an existing container app
13
13
14
14
You can configure Dapr using various [arguments and annotations][dapr-args] based on the runtime context. Azure Container Apps provides three channels through which you can enable Dapr:
0 commit comments