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: daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md
+99-2Lines changed: 99 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,8 +26,7 @@ If you are just getting started, it is recommended to use workload identity fede
26
26
27
27
## Managed identities and workload identity federation
28
28
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.
30
-
29
+
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. You can also setup Microsoft Entra ID to federate trust to your Dapr application identity directly by using a [Federated Identity Credential](https://learn.microsoft.com/graph/api/resources/federatedidentitycredentials-overview?view=graph-rest-1.0). This allows you to configure access to your Microsoft resources even when not running on Microsoft infrastructure. To see how to configure Dapr to use a federated identity, see the section on [Authenticating with a Federated Identity Credential](#authenticating-with-a-federated-identity-credential).
31
30
This is done through [system or user assigned managed identities]({{< ref howto-mi.md >}}), or [workload identity federation]({{< ref howto-wif.md >}}).
32
31
33
32
Once using managed identities, your code doesn't have to deal with credentials, which:
@@ -115,6 +114,104 @@ When running on Kubernetes, you can also use references to Kubernetes secrets fo
115
114
116
115
When running on Azure Kubernetes Service (AKS), you can authenticate components using Workload Identity. Refer to the Azure AKS documentation on [enabling Workload Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview) for your Kubernetes resources.
117
116
117
+
#### Authenticating with a Federated Identity Credential
118
+
119
+
You can use a [Federated Identity Credential](https://learn.microsoft.com/graph/api/resources/federatedidentitycredentials-overview?view=graph-rest-1.0) in Microsoft Entra ID to federate trust directly to your Dapr installation regardless of where it is running. This allows you to easily configure access rules against your Dapr application's [SPIFFE](https://spiffe.io/) ID consistently across different clouds.
120
+
121
+
In order to federate trust, you must be running Dapr Sentry with JWT issuing and OIDC discovery enabled. These can be configured using the following Dapr Sentry helm values:
122
+
123
+
```yaml
124
+
jwt:
125
+
# Enable JWT token issuance by Sentry
126
+
enabled: true
127
+
# Issuer value for JWT tokens
128
+
issuer: "<your-issuer-domain>"
129
+
130
+
oidc:
131
+
enabled: true
132
+
server:
133
+
# Port for the OIDC HTTP server
134
+
port: 9080
135
+
tls:
136
+
# Enable TLS for the OIDC HTTP server
137
+
enabled: true
138
+
# TLS certificate file for the OIDC HTTP server
139
+
certFile: "<path-to-tls-cert.pem>"
140
+
# TLS certificate file for the OIDC HTTP server
141
+
keyFile: "<path-to-tls-key.pem>"
142
+
```
143
+
144
+
{{% alert title="Warning" color="warning" %}}
145
+
The `issuer` value must match exactly the value you provide when creating the Federated Identity Credential in Microsoft Entra ID.
146
+
{{% /alert %}}
147
+
148
+
Providing these settings exposes the following endpoints on your Dapr Sentry installation on the provided OIDC HTTP port:
149
+
```
150
+
/.well-known/openid-configuration
151
+
/jwks.json
152
+
```
153
+
154
+
You also need to provide the Dapr runtime configuration to request a JWT token with the Azure audience `api://AzureADTokenExchange`.
155
+
When running in standalone mode, this can be provided using the flag `--sentry-request-jwt-audiences=api://AzureADTokenExchange`.
156
+
When running in Kubernetes, this can be provided by decorating the application Kubernetes manifest with the annotations `"dapr.io/sentry-request-jwt-audiences": "api://AzureADTokenExchange"`.
157
+
This ensures Sentry service issues a JWT token with the correct audience, which is required for Microsoft Entra ID to validate the token.
158
+
159
+
In order for Microsoft Entra ID to be able to access the OIDC endpoints, you must expose them on a public address. You must ensure that the domain that you are serving these endpoints via is the same as the issuer you provided when configuration Dapr Sentry.
160
+
161
+
You can now create your federated credential in Microsoft Entra ID.
az ad app federated-credential create --id $APP_ID --parameters ./creds.json
177
+
```
178
+
179
+
Now that you have a federated credential for your Microsoft Entra ID Application Registration, you can assign the desired roles to it's service principal.
180
+
181
+
An example of assigning "Storage Blob Data Owner" role is below.
182
+
```shell
183
+
az role assignment create --assignee-object-id $APP_ID --assignee-principal-type ServicePrincipal --role "Storage Blob Data Owner" --scope "/subscriptions/$SUBSCRIPTION/resourceGroups/$GROUP/providers/Microsoft.Storage/storageAccounts/$ACCOUNT_NAME"
184
+
```
185
+
186
+
To configure a Dapr Component to access an Azure resource using the federated credentail, you first need to fetch your `clientId` and `tenantId`:
187
+
```shell
188
+
CLIENT_ID=$(az ad app show --id $APP_ID --query appId --output tsv)
189
+
TENANT_ID=$(az account show --query tenantId --output tsv)
190
+
```
191
+
192
+
Then you can create your Azure Dapr Component and simply provide these value:
193
+
```yaml
194
+
apiVersion: dapr.io/v1alpha1
195
+
kind: Component
196
+
metadata:
197
+
name: azureblob
198
+
spec:
199
+
type: state.azure.blobstorage
200
+
version: v2
201
+
initTimeout: 10s# Increase the init timeout to allow enough time for Azure to perform the token exchange
202
+
metadata:
203
+
- name: clientId
204
+
value: $CLIENT_ID
205
+
- name: tenantId
206
+
value: $TENANT_ID
207
+
- name: accountName
208
+
value: $ACCOUNT_NAME
209
+
- name: containerName
210
+
value: $CONTAINER_NAME
211
+
```
212
+
213
+
The Dapr runtime uses these details to authenticate with Microsoft Entra ID, using the Dapr Sentry issued JWT token to exchange for an access token to access the Azure resource.
214
+
118
215
#### Authenticating using Azure CLI credentials (development-only)
119
216
120
217
> **Important:** This authentication method is recommended for **development only**.
0 commit comments