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
24
25
25
> [!NOTE]
26
26
> The `azureClientId` metadata field (the client ID of the managed identity) is **required** for any component authenticating with user-assigned managed identity.
27
27
28
-
###Using a Dapr secret store component reference
28
+
## Using a Dapr secret store component reference
29
29
30
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
31
@@ -34,14 +34,14 @@ To set up a reference:
34
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
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
36
37
-
####Creating a Dapr secret store component
37
+
### Creating a Dapr secret store component
38
38
39
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
40
41
41
-[For an **Azure Key Vault secret store**,](#using-managed-identity) use managed identity to establish the connection.
42
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
43
44
-
#####Azure Key Vault secret stores
44
+
#### Azure Key Vault secret stores
45
45
46
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
47
@@ -60,7 +60,7 @@ scopes:
60
60
- subscriber-app
61
61
```
62
62
63
-
##### Platform-managed Kubernetes secrets
63
+
#### Platform-managed Kubernetes secrets
64
64
65
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
66
@@ -88,7 +88,7 @@ scopes:
88
88
- subscriber-app
89
89
```
90
90
91
-
#### Referencing Dapr secret store components
91
+
### Referencing Dapr secret store components
92
92
93
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.
0 commit comments