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
Copy file name to clipboardExpand all lines: articles/container-apps/dapr-component-connect-services.md
+21-14Lines changed: 21 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,33 +1,39 @@
1
1
---
2
-
title: Connect to external services via Dapr components
2
+
title: Connect to other Azure or third-party services via Dapr components
3
3
description: Learn more about connecting Dapr components with Azure and external services.
4
4
ms.author: hannahhunter
5
5
author: hhunter-ms
6
6
ms.service: azure-container-apps
7
7
ms.custom: build-2023
8
8
ms.topic: conceptual
9
-
ms.date: 09/23/2024
9
+
ms.date: 12/03/2024
10
10
---
11
11
12
-
# Connect to external services via Dapr components
12
+
# Connect to other Azure or third-party services via Dapr components
13
13
14
-
Securely establish connections to Azure and external services for Dapr components using any of the following approaches.
14
+
Securely establish connections to Azure and third-party services for Dapr components using managed identity or Azure Key Vault secret stores. Before you get started, [learn more about the Tier 1 and Tier 2 levels of support for Dapr components.][dapr-tiers]
Whenever possible, we recommend using Azure components that provide managed identity support for the most secure connection. Use Azure Key Vault secret stores *only* when managed identity authentication isn't supported.
22
19
23
-
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.
20
+
| Service type | Recommendation |
21
+
| ------------ | -------------- |
22
+
| Azure component with managed identity support |[Use the managed identity flow (recommended)](#using-managed-identity-recommended)|
23
+
| Azure component without managed identity support |[Use an Azure Key Vault secret store](#azure-key-vault-secret-stores)|
24
+
| Non-Azure components |[Use an Azure Key Vault secret store](#azure-key-vault-secret-stores)|
25
+
26
+
27
+
## Using managed identity (recommended)
28
+
29
+
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 recommended** as it eliminates storage of sensitive input in components and doesn't require managing a secret store.
24
30
25
31
> [!NOTE]
26
32
> The `azureClientId` metadata field (the client ID of the managed identity) is **required** for any component authenticating with user-assigned managed identity.
27
33
28
34
## Using a Dapr secret store component reference
29
35
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.
36
+
When you create Dapr components for non-Entra ID enabled services or components that don't support managed identity authentication, certain metadata fields require sensitive input values. For this approach, retrieve these secrets by referencing an existing Dapr secret store component that securely accesses secret information.
31
37
32
38
To set up a reference:
33
39
@@ -43,7 +49,7 @@ When creating a secret store component in Azure Container Apps, you can provide
43
49
44
50
#### Azure Key Vault secret stores
45
51
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.
52
+
The following component schema showcases the simplest possible secret store configuration using an Azure Key Vault secret store. `publisher-app` and `subscriber-app` are configured to both have a system or user-assigned managed identity with appropriate permissions on the Azure Key Vault instance.
47
53
48
54
```yaml
49
55
componentType: secretstores.azure.keyvault
@@ -62,9 +68,9 @@ scopes:
62
68
63
69
#### Platform-managed Kubernetes secrets
64
70
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.
71
+
As an alternative to Kubernetes secrets, Local environment variables, and Local file Dapr secret stores, Azure Container Apps provides a platform-managed approach for creating and leveraging Kubernetes secrets. 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.
66
72
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.
73
+
This component configuration defines the sensitive value as a secret parameter that can be referenced from the metadata section.
0 commit comments