From dcf18094ee94fde440735eee22fe788c61c1fce6 Mon Sep 17 00:00:00 2001 From: Jonathan Collinge Date: Sun, 11 May 2025 08:42:39 +0100 Subject: [PATCH 1/5] Add initial docs for Azure federated identity credential Signed-off-by: Jonathan Collinge --- .../authenticating-azure.md | 81 ++++++++++++++++++- 1 file changed, 80 insertions(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md b/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md index 329fad5c6c4..d7cf2d8c38b 100644 --- a/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md +++ b/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md @@ -31,7 +31,7 @@ Some Azure components offer alternative authentication methods, such as systems ### Managed Identities and Workload Identity -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. +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/en-us/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). Once using MI, your code doesn't have to deal with credentials, which: @@ -112,6 +112,85 @@ When running on Kubernetes, you can also use references to Kubernetes secrets fo 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. +#### Authenticating with a Federated Identity Credential + +You can use a [Federated Identity Credential](https://learn.microsoft.com/en-us/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. + +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: + +```yaml +jwt: + enabled: true + issuer: + audiences: + - "api://AzureADTokenExchange" + +oidc: + httpPort: 9082 # any none zero port + tls: + certFile: /path/to/tls/cert.pem + keyFile: /path/to/tls/key.pem +``` + +This will expose the following endpoints on your Dapr Sentry installation on the provided OIDC HTTP port: +``` +/.well-known/openid-configuration +/jwks.json +``` + +In order for Microsoft Entra ID to be able to access those 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 or added to the list of supported OIDC domains via the helm value `oidc.domains`. + +You can now create your federated credential in Microsoft Entra ID. + +```shell +cat > creds.json <", + "subject": spiffe://public/ns//", + "audiences": ["api://AzureADTokenExchange"], + "description": "Credential for Dapr App ID" +} +EOF + +export APP_ID=$(az ad app create --display-name my-dapr-app --enable-access-token-issuance --enable-id-token-issuance | jq .id) +az ad sp create --id $APP_ID +az ad app federated-credential create --id $APP_ID --parameters ./creds.json +``` + +Now that you have a federated credential for you Microsoft Entra ID Application Registration, you can assign the desired roles to it's service principal. + +An example of assigning "Storage Blob Data Owner" role is below +```shell +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" +``` + +To configure a Dapr Component to access an Azure resource using the federated credentail, you first need to fetch your `clientId` and `tenantId`: +```shell +CLIENT_ID=$(az ad app show --id $APP_ID --query appId --output tsv) +TENANT_ID=$(az account show --query tenantId --output tsv) +``` + +Then you can create your Azure Dapr Component and simply provide those value: +```yaml +apiVersion: dapr.io/v1alpha1 +kind: Component +metadata: + name: azureblob +spec: + type: state.azure.blobstorage + version: v2 + metadata: + - name: clientId + value: $CLIENT_ID + - name: tenantId + value: $TENANT_ID + - name: accountName + value: $ACCOUNT_NAME + - name: containerName + value: $CONTAINER_NAME +``` + #### Authenticating using Azure CLI credentials (development-only) > **Important:** This authentication method is recommended for **development only**. From 946f988fc2a345fccfea01b292754ab8ac7baf0b Mon Sep 17 00:00:00 2001 From: Jonathan Collinge Date: Mon, 19 May 2025 08:03:55 +0100 Subject: [PATCH 2/5] Add audiences to access control struct docs Signed-off-by: Jonathan Collinge --- daprdocs/content/en/operations/configuration/invoke-allowlist.md | 1 + 1 file changed, 1 insertion(+) diff --git a/daprdocs/content/en/operations/configuration/invoke-allowlist.md b/daprdocs/content/en/operations/configuration/invoke-allowlist.md index f9afe029926..62c3d9b6219 100644 --- a/daprdocs/content/en/operations/configuration/invoke-allowlist.md +++ b/daprdocs/content/en/operations/configuration/invoke-allowlist.md @@ -40,6 +40,7 @@ The following tables lists the different properties for access control, policies |---------------|--------|-------------| | `defaultAction` | string | Global default action when no other policy is matched | `trustDomain` | string | Trust domain assigned to the application. Default is "public". +| `audiences` | string | A list of audiences for the application's identity JWT. | `policies` | string | Policies to determine what operations the calling app can do on the called app ### Policies From 7c0fb2c7cab217ff85a5d77a3137b2c3d0aadf0b Mon Sep 17 00:00:00 2001 From: Jonathan Collinge Date: Mon, 23 Jun 2025 13:19:32 +0100 Subject: [PATCH 3/5] Update helm values Signed-off-by: Jonathan Collinge --- .../authenticating-azure.md | 42 ++++++++++++------- 1 file changed, 28 insertions(+), 14 deletions(-) diff --git a/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md b/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md index d7cf2d8c38b..8869ccc96bc 100644 --- a/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md +++ b/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md @@ -120,16 +120,23 @@ In order to federate trust, you must be running Dapr Sentry with JWT issuing and ```yaml jwt: + # Enable JWT token issuance by Sentry enabled: true - issuer: - audiences: - - "api://AzureADTokenExchange" + # Issuer value for JWT tokens + issuer: "" oidc: - httpPort: 9082 # any none zero port + enabled: true + server: + # Port for the OIDC HTTP server + port: 9080 tls: - certFile: /path/to/tls/cert.pem - keyFile: /path/to/tls/key.pem + # Enable TLS for the OIDC HTTP server + enabled: true + # TLS certificate file for the OIDC HTTP server + certFile: "" + # TLS certificate file for the OIDC HTTP server + keyFile: "" ``` This will expose the following endpoints on your Dapr Sentry installation on the provided OIDC HTTP port: @@ -138,18 +145,23 @@ This will expose the following endpoints on your Dapr Sentry installation on the /jwks.json ``` -In order for Microsoft Entra ID to be able to access those 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 or added to the list of supported OIDC domains via the helm value `oidc.domains`. +You will also need to provide the Dapr runtime configuration to request a JWT token with the Azure audience `api://AzureADTokenExchange`. +When running in standalone, this can be provided using the flag `--jwt-audiences=api://AzureADTokenExchange`. +When running in Kubernetes, this can be provided by decorating the application Kubernetes manifest with the annotations `"dapr.io/jwt-audiences": "api://AzureADTokenExchange"`. +This will ensure Sentry issues a JWT token with the correct audience, which is required for Microsoft Entra ID to validate the token. + +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. You can now create your federated credential in Microsoft Entra ID. ```shell cat > creds.json <", + "name": "DaprAppIDSpiffe", + "issuer": "https://", "subject": spiffe://public/ns//", - "audiences": ["api://AzureADTokenExchange"], - "description": "Credential for Dapr App ID" + "audiences": ["api://AzureADTokenExchange"], + "description": "Credential for Dapr App ID" } EOF @@ -158,9 +170,9 @@ az ad sp create --id $APP_ID az ad app federated-credential create --id $APP_ID --parameters ./creds.json ``` -Now that you have a federated credential for you Microsoft Entra ID Application Registration, you can assign the desired roles to it's service principal. +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. -An example of assigning "Storage Blob Data Owner" role is below +An example of assigning "Storage Blob Data Owner" role is below. ```shell 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" ``` @@ -171,7 +183,7 @@ CLIENT_ID=$(az ad app show --id $APP_ID --query appId --output tsv) TENANT_ID=$(az account show --query tenantId --output tsv) ``` -Then you can create your Azure Dapr Component and simply provide those value: +Then you can create your Azure Dapr Component and simply provide these value: ```yaml apiVersion: dapr.io/v1alpha1 kind: Component @@ -191,6 +203,8 @@ spec: value: $CONTAINER_NAME ``` +The Dapr runtime will use 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. + #### Authenticating using Azure CLI credentials (development-only) > **Important:** This authentication method is recommended for **development only**. From d2ca86aadbf8428d7c1b60feccaabaaac09b5676 Mon Sep 17 00:00:00 2001 From: Jonathan Collinge Date: Mon, 23 Jun 2025 14:24:44 +0100 Subject: [PATCH 4/5] Remove jwt audiences from configuration Signed-off-by: Jonathan Collinge --- daprdocs/content/en/operations/configuration/invoke-allowlist.md | 1 - 1 file changed, 1 deletion(-) diff --git a/daprdocs/content/en/operations/configuration/invoke-allowlist.md b/daprdocs/content/en/operations/configuration/invoke-allowlist.md index 62c3d9b6219..f9afe029926 100644 --- a/daprdocs/content/en/operations/configuration/invoke-allowlist.md +++ b/daprdocs/content/en/operations/configuration/invoke-allowlist.md @@ -40,7 +40,6 @@ The following tables lists the different properties for access control, policies |---------------|--------|-------------| | `defaultAction` | string | Global default action when no other policy is matched | `trustDomain` | string | Trust domain assigned to the application. Default is "public". -| `audiences` | string | A list of audiences for the application's identity JWT. | `policies` | string | Policies to determine what operations the calling app can do on the called app ### Policies From 3dc1950e83cf9e525367def86ff36140f54e1b92 Mon Sep 17 00:00:00 2001 From: Jonathan Collinge Date: Mon, 23 Jun 2025 15:04:20 +0100 Subject: [PATCH 5/5] Add warning Signed-off-by: Jonathan Collinge --- .../Azure/azure-authentication/authenticating-azure.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md b/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md index 8869ccc96bc..8575e6156c5 100644 --- a/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md +++ b/daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md @@ -139,7 +139,11 @@ oidc: keyFile: "" ``` -This will expose the following endpoints on your Dapr Sentry installation on the provided OIDC HTTP port: +{{% alert title="Warning" color="warning" %}} +The `issuer` value must match exactly the value you provide when creating the Federated Identity Credential in Microsoft Entra ID. +{{% /alert %}} + +Providing these settings will expose the following endpoints on your Dapr Sentry installation on the provided OIDC HTTP port: ``` /.well-known/openid-configuration /jwks.json