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
* Add Azure workload identity federation doc.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Shortcodes.
Signed-off-by: Alexander Trauzzi <[email protected]>
* De-localize Microsoft links.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Remove references to pod identities.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Add system and user managed identity comparison.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Add a second reference to the sample app.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Apply suggestions from code review
Co-authored-by: Mark Fussell <[email protected]>
Signed-off-by: Alexander Trauzzi <[email protected]>
* Portability note.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Relocate some content to main azure auth guide and reflow.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Make another mention of Dapr guides within the main doc.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Reflow authenticating azure some more.
Signed-off-by: Alexander Trauzzi <[email protected]>
* Reflow authenticating azure some more.
Signed-off-by: Alexander Trauzzi <[email protected]>
---------
Signed-off-by: Alexander Trauzzi <[email protected]>
Co-authored-by: Mark Fussell <[email protected]>
Copy file name to clipboardExpand all lines: daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md
+20-17Lines changed: 20 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,38 +9,41 @@ aliases:
9
9
weight: 10000
10
10
---
11
11
12
-
Most Azure components for Dapr support authenticating with Microsoft Entra ID. Thanks to this:
13
-
14
-
- Administrators can leverage all the benefits of fine-tuned permissions with Azure Role-Based Access Control (RBAC).
15
-
- 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)](https://learn.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) and [Workload Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview). These offer the ability to authenticate your applications without having to manage sensitive credentials.
16
-
17
12
## About authentication with Microsoft Entra ID
18
13
19
-
Microsoft Entra ID is Azure's identity and access management (IAM) solution, which is used to authenticate and authorize users and services.
14
+
Microsoft Entra ID is Azure's identity and access management (IAM) solution, which is used to authenticate and authorize users and services. It's 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.
20
15
21
-
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.
16
+
## Options to authenticate
22
17
23
-
> In Azure terminology, an application is also called a "Service Principal".
18
+
Applications can authenticate with Microsoft Entra ID and obtain an access token to make requests to Azure services through several methods:
24
19
25
-
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:
20
+
-[Workload identity federation]({{< ref howto-wif.md >}}) - The recommended way to configure your Microsoft Entra ID tenant to trust an external identity provider. This includes service accounts from Kubernetes or AKS clusters. [Learn more about workload identity federation](https://learn.microsoft.com/entra/workload-id/workload-identities-overview).
21
+
-[System and user assigned managed identities]({{< ref howto-mi.md >}}) - Less granular than workload identity federation, but retains some of the benefits. [Learn more about system and user assigned managed identities](https://learn.microsoft.com/azure/aks/use-managed-identity).
22
+
-[Client ID and secret]({{ < ref howto-aad.md >}}) - Not recommended as it requires you to maintian and associate credentials at the application level.
23
+
- Pod Identities - [Deprecated approach for authenticating applications running on Kubernetes pods](https://learn.microsoft.com/azure/aks/use-azure-ad-pod-identity) at a pod level. This should no longer be used.
26
24
27
-
-[Managed Identities and Workload Identity](#managed-identities-and-workload-identity)
-[(Optional) Authentication using certificates](#optional-authentication-using-certificates)
25
+
If you are just getting started, it is recommended to use workload identity federation.
26
+
27
+
## Managed identities and workload identity federation
31
28
32
-
### Managed Identities and Workload Identity
29
+
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.
33
30
34
-
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.
31
+
This is done through [system or user assigned managed identities]({{< ref howto-mi.md >}}), or [workload identity federation]({{< ref howto-wif.md >}}).
35
32
36
-
Once using MI, your code doesn't have to deal with credentials, which:
33
+
Once using managed identities, your code doesn't have to deal with credentials, which:
37
34
38
35
- Removes the challenge of managing credentials safely
39
36
- Allows greater separation of concerns between development and operations teams
40
37
- Reduces the number of people with access to credentials
41
38
- Simplifies operational aspects–especially when multiple environments are used
42
39
43
-
Applications running on Azure Kubernetes Service can similarly leverage [Workload Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview) to automatically provide an identity to individual pods.
40
+
While some Dapr Azure components offer alternative authentication methods, such as systems based on "shared keys" or "access tokens", you should always try to authenticate your Dapr components using Microsoft Entra ID whenever possible. This offers many benefits, including:
-[(Optional) Authentication using certificates](#optional-authentication-using-certificates)
45
+
46
+
It's recommended that applications running on Azure Kubernetes Service leverage [workload identity federation](https://learn.microsoft.com/entra/workload-id/workload-identity-federation) to automatically provide an identity to individual pods.
is a way for your applications to authenticate to Azure without having to store or manage credentials as part of
15
+
your releases.
16
+
17
+
By using workload identity federation, any Dapr components running on Kubernetes and AKS that target Azure can authenticate transparently
18
+
with no extra configuration.
19
+
20
+
## Guide
21
+
22
+
We'll show how to configure an Azure Key Vault resource against your AKS cluster. You can adapt this guide for different
23
+
Dapr Azure components by substituting component definitions as necessary.
24
+
25
+
For this How To, we'll use this [Dapr AKS secrets sample app](https://github.com/dapr/samples/dapr-aks-workload-identity-federation).
26
+
27
+
### Prerequisites
28
+
29
+
- AKS cluster with workload identity enabled
30
+
- Microsoft Entra ID tenant
31
+
32
+
### 1 - Enable workload identity federation
33
+
34
+
Follow [the Azure documentation for enabling workload identity federation on your AKS cluster](https://learn.microsoft.com/azure/aks/workload-identity-deploy-cluster#deploy-your-application4).
35
+
36
+
The HowTo walks through configuring your Azure Entra ID tenant to trust an identity that originates from your AKS cluster issuer.
37
+
It also guides you in setting up a [Kubernetes service account](https://kubernetes.io/docs/concepts/security/service-accounts/) which
38
+
is associated with an Azure managed identity you create.
39
+
40
+
Once completed, return here to continue with step 2.
41
+
42
+
### 2 - Add a secret to Azure Key Vault
43
+
44
+
In the Azure Key Vault you created and add a secret called `dapr` with the value of `Hello Dapr!`.
45
+
46
+
### 3 - Configure the Azure Key Vault dapr component
47
+
48
+
By this point, you should have a Kubernetes service account with a name similar to `workload-identity-sa0a1b2c`.
49
+
50
+
Apply the following to your Kubernetes cluster, remembering to update `your-key-vault` with the name of your key vault:
51
+
52
+
```yaml
53
+
---
54
+
apiVersion: dapr.io/v1alpha1
55
+
kind: Component
56
+
metadata:
57
+
name: demo-secret-store # Be sure not to change this, as our app will be looking for it.
58
+
spec:
59
+
type: secretstores.azure.keyvault
60
+
version: v1
61
+
metadata:
62
+
- name: vaultName
63
+
value: your-key-vault # Replace
64
+
```
65
+
66
+
You'll notice that we have not provided any details specific to authentication in the component definition. This is intentional, as Dapr is able to leverage the Kubernetes service account to transparently authenticate to Azure.
67
+
68
+
### 4 - Deploy the test application
69
+
70
+
Go to the [workload identity federation sample application](https://github.com/dapr/samples/dapr-aks-workload-identity-federation) and prepare a build of the image.
71
+
72
+
Make sure the image is pushed up to a registry that your AKS cluster has visibility and permission to pull from.
73
+
74
+
Next, create a deployment for our sample AKS secrets app container along with a Dapr sidecar.
75
+
76
+
Remember to update `dapr-wif-k8s-service-account` with your service account name and `dapraksworkloadidentityfederation` with an image your cluster can resolve:
77
+
78
+
79
+
```yaml
80
+
---
81
+
apiVersion: apps/v1
82
+
kind: Deployment
83
+
metadata:
84
+
name: aks-dapr-wif-secrets
85
+
labels:
86
+
app: aks-dapr-wif-secrets
87
+
spec:
88
+
replicas: 1
89
+
selector:
90
+
matchLabels:
91
+
app: aks-dapr-wif-secrets
92
+
template:
93
+
metadata:
94
+
labels:
95
+
app: aks-dapr-wif-secrets
96
+
azure.workload.identity/use: "true" # Important
97
+
annotations:
98
+
dapr.io/enabled: "true" # Enable Dapr
99
+
dapr.io/app-id: "aks-dapr-wif-secrets"
100
+
spec:
101
+
serviceAccountName: dapr-wif-k8s-service-account # Remember to replace
102
+
containers:
103
+
- name: workload-id-demo
104
+
image: dapraksworkloadidentityfederation # Remember to replace
105
+
imagePullPolicy: Always
106
+
```
107
+
Once the application is up and running, it should output the following:
Copy file name to clipboardExpand all lines: daprdocs/content/en/reference/components-reference/supported-secret-stores/azure-keyvault.md
+2-19Lines changed: 2 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -297,31 +297,14 @@ In Kubernetes, you store the client secret or the certificate into the Kubernete
297
297
```bash
298
298
kubectl apply -f azurekeyvault.yaml
299
299
```
300
-
1. Create and assign a managed identity at the pod-level via either:
301
-
- [Microsoft Entra ID workload identity](https://learn.microsoft.com/azure/aks/workload-identity-overview) (preferred method)
302
-
- [Microsoft Entra ID pod identity](https://docs.microsoft.com/azure/aks/use-azure-ad-pod-identity#create-a-pod-identity)
303
-
304
-
305
-
**Important**: While both Microsoft Entra ID pod identity and workload identity are in preview, currently Microsoft Entra ID Workload Identity is planned for general availability (stable state).
300
+
1. Create and assign a managed identity at the pod-level via [Microsoft Entra ID workload identity](https://learn.microsoft.com/azure/aks/workload-identity-overview)
306
301
307
302
1. After creating a workload identity, give it `read` permissions:
308
303
- [On your desired KeyVault instance](https://docs.microsoft.com/azure/key-vault/general/assign-access-policy?tabs=azure-cli#assign-the-access-policy)
309
-
- In your application deployment. Inject the pod identity both:
310
-
- Via a label annotation
311
-
- By specifying the Kubernetes service account associated with the desired workload identity
312
-
313
-
```yaml
314
-
apiVersion: v1
315
-
kind: Pod
316
-
metadata:
317
-
name: mydaprdemoapp
318
-
labels:
319
-
aadpodidbinding: $POD_IDENTITY_NAME
320
-
```
321
304
322
305
#### Using Azure managed identity directly vs. via Microsoft Entra ID workload identity
323
306
324
-
When using **managed identity directly**, you can have multiple identities associated with an app, requiring `azureClientId` to specify which identity should be used.
307
+
When using **managed identity directly**, you can have multiple identities associated with an app, requiring `azureClientId` to specify which identity should be used.
325
308
326
309
However, when using **managed identity via Microsoft Entra ID workload identity**, `azureClientId` is not necessary and has no effect. The Azure identity to be used is inferred from the service account tied to an Azure identity via the Azure federated identity.
0 commit comments