与 Azure 的集成

• 1: 对 Azure 进行身份验证
• 1.1: 向 Azure 进行身份验证
• 1.2: 如何使用工作负载身份联合
• 1.3: 操作指南：生成新的 Microsoft Entra ID 应用程序和服务主体
• 1.4: 如何：使用托管标识
• 2: Azure API Management 的 Dapr 集成策略
• 3: Dapr extension for Azure Functions runtime
• 4: 适用于 Azure Kubernetes Service (AKS) 的 Dapr 扩展

1 - 对 Azure 进行身份验证

1.1 - 向 Azure 进行身份验证

关于使用 Microsoft Entra ID 进行身份验证

Microsoft Entra ID 是 Azure 的标识和访问管理 (IAM) 解决方案，用于对用户和服务进行身份验证和授权。它构建在 OAuth 2.0 等开放标准之上，允许服务（应用程序）获取访问令牌以向 Azure 服务发出请求，包括 Azure Storage、Azure Service Bus、Azure Key Vault、Azure Cosmos DB、Azure Database for Postgres、Azure SQL 等。

身份验证选项

应用程序可以通过多种方法使用 Microsoft Entra ID 进行身份验证并获取访问令牌以向 Azure 服务发出请求：

• 工作负载标识联合 - 配置 Microsoft Entra ID 租户以信任外部标识提供者的推荐方式。这包括来自 Kubernetes 或 AKS 集群的服务账户。了解有关工作负载标识联合的更多信息。
• 系统分配和用户分配的托管标识 - 不如工作负载标识联合精细，但保留了部分优势。了解有关系统分配和用户分配的托管标识的更多信息。
• [客户端 ID 和密钥]({{ < ref howto-aad.md >}}) - 不推荐，因为它要求您在应用程序级别维护和关联凭据。
• Pod 标识 - 已弃用的方法，用于对在 Kubernetes Pod 上运行的应用程序进行身份验证，在 Pod 级别进行。不应再使用此方法。

如果您刚刚开始，建议使用工作负载标识联合。

托管标识和工作负载标识联合

使用托管标识 (MI)，您的应用程序可以使用 Microsoft Entra ID 进行身份验证并获取访问令牌以向 Azure 服务发出请求。当您的应用程序在支持的 Azure 服务（例如 Azure VM、Azure Container Apps、Azure Web Apps 等）上运行时，可以在基础设施级别为您的应用程序分配标识。您还可以设置 Microsoft Entra ID 以使用联合标识凭据直接将联合信任委托给您的 Dapr 应用程序标识。这允许您配置对 Microsoft 资源的访问权限，即使不在 Microsoft 基础设施上运行也是如此。要了解如何配置 Dapr 以使用联合标识，请参阅使用联合标识凭据进行身份验证部分。 这是通过系统分配或用户分配的托管标识或工作负载标识联合完成的。

使用托管标识后，您的代码不必处理凭据，这可以：

• 消除安全管理凭据的挑战
• 允许开发团队和运营团队之间更好地分离关注点
• 减少有权访问凭据的人数
• 简化操作方面——尤其是在使用多个环境时

虽然某些 Dapr Azure 组件提供替代身份验证方法，例如基于"共享密钥"或"访问令牌"的系统，但只要有可能，您应该始终尝试使用 Microsoft Entra ID 对 Dapr 组件进行身份验证。这提供了许多好处，包括：

• 基于角色的访问控制
• 审核
• (可选) 使用证书进行身份验证

建议在 Azure Kubernetes Service 上运行的应用程序利用工作负载标识联合自动为各个 Pod 提供标识。

基于角色的访问控制

在对受支持的服务使用 Azure 基于角色的访问控制 (RBAC) 时，可以微调授予应用程序的权限。例如，您可以限制对数据子集的访问或使访问变为只读。

审核

使用 Microsoft Entra ID 可提供改进的访问审核体验。租户管理员可以查看审核日志以跟踪身份验证请求。

(可选) 使用证书进行身份验证

虽然 Microsoft Entra ID 允许您使用 MI，但您仍然可以选择使用证书进行身份验证。

对其他 Azure 环境的支持

默认情况下，Dapr 组件配置为与"公有云"中的 Azure 资源进行交互。如果您的应用程序部署到另一个云，例如 Azure China 或 Azure Government（“主权云”），可以通过将 azureEnvironment 元数据属性设置为支持的值之一，为支持的组件启用该功能：

• Azure 公有云（默认）: "AzurePublicCloud"
• Azure 中国: "AzureChinaCloud"
• Azure 政府: "AzureUSGovernmentCloud"

对主权云的支持是实验性的。

凭据元数据字段

要使用 Microsoft Entra ID 进行身份验证，您需要将以下凭据作为值添加到您的 Dapr 组件的元数据中。

元数据选项

根据您如何将凭据传递给 Dapr 服务，您有多个元数据选项。

• 使用客户端凭据
• 使用证书
• 使用托管标识 (MI)
• 在 AKS 上使用工作负载标识
• 使用 Azure CLI 凭据（仅限开发）

使用客户端凭据进行身份验证

在 Kubernetes 上运行时，您还可以对上述任何或所有值使用对 Kubernetes 机密的引用。

使用证书进行身份验证

在 Kubernetes 上运行时，您还可以对上述任何或所有值使用对 Kubernetes 机密的引用。

使用托管标识 (MI) 进行身份验证

使用托管标识，通常推荐使用 azureClientId 字段。使用系统分配的标识时，该字段是可选的，但在使用用户分配的标识时可能是必需的。

在 AKS 上使用工作负载标识进行身份验证

在 Azure Kubernetes Service (AKS) 上运行时，您可以使用工作负载标识对组件进行身份验证。请参阅 Azure AKS 文档中关于为 Kubernetes 资源启用工作负载标识的内容。

使用联合标识凭据进行身份验证

您可以使用 Microsoft Entra ID 中的联合标识凭据直接将联合信任委托给您的 Dapr 安装，无论其运行在何处。这允许您跨不同云一致地针对 Dapr 应用程序的 SPIFFE ID 轻松配置访问规则。

为了联合信任，您必须运行启用了 JWT 颁发和 OIDC 发现的 Dapr Sentry。可以使用以下 Dapr Sentry helm 值配置这些功能：

jwt:
  # 通过 Sentry 启用 JWT 令牌颁发
  enabled: true
  # JWT 令牌的颁发者值
  issuer: "<your-issuer-domain>"

oidc:
  enabled: true
  server:
    # OIDC HTTP 服务器的端口
    port: 9080
  tls:
    # 为 OIDC HTTP 服务器启用 TLS
    enabled: true
    # OIDC HTTP 服务器的 TLS 证书文件
    certFile: "<path-to-tls-cert.pem>"
    # OIDC HTTP 服务器的 TLS 证书文件
    keyFile: "<path-to-tls-key.pem>"

提供这些设置后，在提供的 OIDC HTTP 端口上的 Dapr Sentry 安装上会公开以下端点：

/.well-known/openid-configuration
/jwks.json

您还需要提供 Dapr 运行时配置以请求具有 Azure 受众 api://AzureADTokenExchange 的 JWT 令牌。 在独立模式下运行时，可以使用标志 --sentry-request-jwt-audiences=api://AzureADTokenExchange 提供。 在 Kubernetes 上运行时，可以通过使用注解 "dapr.io/sentry-request-jwt-audiences": "api://AzureADTokenExchange" 修饰应用程序 Kubernetes 清单来提供。 这可确保 Sentry 服务颁发具有正确受众的 JWT 令牌，这是 Microsoft Entra ID 验证令牌所必需的。

为了使 Microsoft Entra ID 能够访问 OIDC 端点，您必须在公共地址上公开它们。您必须确保提供这些端点的域与配置 Dapr Sentry 时提供的颁发者相同。

现在您可以在 Microsoft Entra ID 中创建联合凭据。

cat > creds.json <<EOF
{ 
  "name": "DaprAppIDSpiffe",
  "issuer": "https://<your-issuer-domain>",
  "subject": spiffe://public/ns/<dapr-app-id-namespace>/<dapr-app-id>",
  "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

现在您已经有了 Microsoft Entra ID 应用程序注册的联合凭据，可以为其服务主体分配所需的角色。

下面是分配"Storage Blob Data Owner"角色的示例。

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"

要配置 Dapr 组件以使用联合凭据访问 Azure 资源，首先需要获取您的 clientId 和 tenantId：

CLIENT_ID=$(az ad app show --id $APP_ID --query appId --output tsv)
TENANT_ID=$(az account show --query tenantId --output tsv)

然后您可以创建 Azure Dapr 组件并只需提供这些值：

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azureblob
spec:
  type: state.azure.blobstorage
  version: v2
  initTimeout: 10s # 增加初始化超时以允许 Azure 有足够的时间执行令牌交换
  metadata:
  - name: clientId
    value: $CLIENT_ID
  - name: tenantId
    value:  $TENANT_ID
  - name: accountName
    value: $ACCOUNT_NAME
  - name: containerName
    value: $CONTAINER_NAME

Dapr 运行时使用这些详细信息通过 Microsoft Entra ID 进行身份验证，使用 Dapr Sentry 颁发的 JWT 令牌交换访问令牌以访问 Azure 资源。

使用 Azure CLI 凭据进行身份验证（仅限开发）

重要提示： 此身份验证方法仅建议用于开发。

此身份验证方法在本地计算机上开发时可能很有用。您需要：

• 已安装 Azure CLI
• 已成功使用 az login 命令进行身份验证

当 Dapr 在有 Azure CLI 凭据可用的主机上运行时，如果没有配置其他身份验证方法，组件可以使用这些凭据自动进行身份验证。

使用此身份验证方法不需要设置任何元数据选项。

在 Dapr 组件中的使用示例

在此示例中，您将设置一个使用 Microsoft Entra ID 进行身份验证的 Azure Key Vault 机密存储组件。

• 自托管
• Kubernetes

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
  namespace: default
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: "[your_keyvault_name]"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureClientSecret
    value : "[your_client_secret]"

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
  namespace: default
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: "[your_keyvault_name]"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureCertificateFile
    value : "[pfx_certificate_file_fully_qualified_local_path]"

后续步骤

参考

• Microsoft Entra ID 应用凭据: Azure CLI 参考
• Azure 托管服务标识 (MSI) 概述
• 机密构建块
• 操作方法: 检索机密
• 操作方法: 在 Dapr 组件中引用机密
• 机密 API 参考

1.2 - 如何使用工作负载身份联合

本指南将帮助你配置 Kubernetes 集群，以在 Azure 上运行 Dapr 并使用工作负载身份联合。

它是什么？

工作负载身份联合 是一种让应用程序向 Azure 进行身份验证的方式，无需在发布过程中存储或管理凭据。

通过使用工作负载身份联合，任何在 Kubernetes 和 AKS 上运行并面向 Azure 的 Dapr 组件都可以透明地进行身份验证，无需额外配置。

指南

我们将演示如何针对 AKS 集群配置 Azure Key Vault 资源。你可以根据需要调整本指南，将其应用于不同的 Dapr Azure 组件。

在本操作指南中，我们将使用此 Dapr AKS secrets 示例应用。

前提条件

• 已启用工作负载身份的 AKS 集群
• Microsoft Entra ID 租户

1 - 启用工作负载身份联合

按照 在 AKS 集群上启用工作负载身份联合的 Azure 文档 进行操作。

该操作指南将引导你配置 Azure Entra ID 租户以信任来自 AKS 集群颁发者的身份。它还会指导你设置一个 Kubernetes 服务账户，该账户与你创建的 Azure 托管标识相关联。

完成后，返回此处继续执行步骤 2。

2 - 向 Azure Key Vault 添加密钥

在你创建的 Azure Key Vault 中，添加一个名为 dapr 的密钥，其值为 Hello Dapr!。

3 - 配置 Azure Key Vault dapr 组件

此时，你应该拥有一个名称类似于 workload-identity-sa0a1b2c 的 Kubernetes 服务账户。

将以下内容应用到你的 Kubernetes 集群，记得将 your-key-vault 替换为你的密钥保管库名称：

---
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: demo-secret-store # 请勿更改此名称，我们的应用将查找它。
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: your-key-vault # 替换

你会注意到，我们在组件定义中没有提供任何与身份验证相关的详细信息。这是有意为之，因为 Dapr 能够利用 Kubernetes 服务账户向 Azure 进行透明身份验证。

4 - 部署测试应用程序

前往 工作负载身份联合示例应用程序 并准备镜像的构建。

确保镜像已推送到你的 AKS 集群可见并有权拉取的注册表。

接下来，为我们的示例 AKS secrets 应用容器创建一个部署，同时包含一个 Dapr 边车。

记得将 dapr-wif-k8s-service-account 替换为你的服务账户名称，将 dapraksworkloadidentityfederation 替换为你的集群可以解析的镜像：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-dapr-wif-secrets
  labels:
    app: aks-dapr-wif-secrets
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-dapr-wif-secrets
  template:
    metadata:
      labels:
        app: aks-dapr-wif-secrets
        azure.workload.identity/use: "true" # 重要
      annotations:
        dapr.io/enabled: "true" # 启用 Dapr
        dapr.io/app-id: "aks-dapr-wif-secrets"
    spec:
      serviceAccountName: dapr-wif-k8s-service-account # 记得替换
      containers:
        - name: workload-id-demo
          image: dapraksworkloadidentityfederation # 记得替换
          imagePullPolicy: Always

应用程序启动并运行后，应该输出以下内容：

Fetched Secret: Hello dapr!

1.3 - 操作指南：生成新的 Microsoft Entra ID 应用程序和服务主体

前置条件

• Azure 订阅
• Azure CLI
• jq
• OpenSSL（默认包含在所有 Linux 和 macOS 系统以及 WSL 中）
• 确保您使用的是 bash 或 zsh shell

使用 Azure CLI 登录 Azure

在新的终端中，运行以下命令：

az login
az account set -s [your subscription id]

创建 Microsoft Entra ID 应用程序

使用以下命令创建 Microsoft Entra ID 应用程序：

# 应用程序 / 服务主体的友好名称
APP_NAME="dapr-application"

# 创建应用程序
APP_ID=$(az ad app create --display-name "${APP_NAME}"  | jq -r .appId)

选择您希望传递凭据的方式。

• Client secret
• PFX certificate

az ad app credential reset \
  --id "${APP_ID}" \
  --years 2

{
  "appId": "<your-app-id>",
  "password": "<your-password>",
  "tenant": "<your-azure-tenant>"
}

az ad app credential reset \
  --id "${APP_ID}" \
  --create-cert

{
  "appId": "<your-app-id>",
  "fileWithCertAndPrivateKey": "<file-path>",
  "password": null,
  "tenant": "<your-azure-tenant>"
}

创建服务主体

创建 Microsoft Entra ID 应用程序后，为该应用程序创建服务主体。使用此服务主体，您可以授予其对 Azure 资源的访问权限。

要创建服务主体，请运行以下命令：

SERVICE_PRINCIPAL_ID=$(az ad sp create \
  --id "${APP_ID}" \
  | jq -r .id)
echo "Service Principal ID: ${SERVICE_PRINCIPAL_ID}"

预期输出：

Service Principal ID: 1d0ccf05-5427-4b5e-8eb4-005ac5f9f163

上面返回的值是 服务主体 ID，它不同于 Microsoft Entra ID 应用程序 ID（客户端 ID）。服务主体 ID 在 Azure 租户内定义，用于授予应用程序对 Azure 资源的访问权限。

您将使用服务主体 ID 来授予应用程序访问 Azure 资源的权限。

同时，客户端 ID 由您的应用程序用于身份验证。您将在 Dapr 清单中使用客户端 ID 来配置与 Azure 服务的身份验证。

请记住，刚刚创建的服务主体默认情况下无权访问任何 Azure 资源。需要根据需要授予对每个资源的访问权限，如组件文档中所述。

后续步骤

1.4 - 如何：使用托管标识

使用托管标识时，身份验证会自动进行，因为你的应用程序运行在已启用系统托管标识或用户分配标识的 Azure 服务之上。

要开始使用，你需要在各种 Azure 服务中启用托管标识作为服务选项/功能，这与 Dapr 无关。启用此功能会在底层为 Microsoft Entra ID（以前称为 Azure Active Directory ID）创建一个标识（或应用程序）。

然后，你的 Dapr 服务可以利用该标识与 Microsoft Entra ID 进行身份验证，这一过程是透明的，无需你指定任何凭据。

在本指南中，你将学习如何：

• 通过官方 Azure 文档向你的标识授予对正在使用的 Azure 服务的访问权限
• 在你的组件中设置系统托管标识或用户分配标识

大概就是这么多了。

向服务授予权限

为特定的 Azure 资源（由资源范围标识）设置所需的 Microsoft Entra ID 角色分配或自定义权限，以应用于你的系统托管标识或用户分配标识。

你可以将托管标识设置到新的或现有的 Azure 资源上。具体说明取决于所使用的服务。请查看以下官方文档以获取最合适的说明：

• Azure Kubernetes Service (AKS)
• Azure Container Apps (ACA)
• Azure App Service（包括 Azure Web Apps 和 Azure Functions）
• Azure Virtual Machines (VM)
• Azure Virtual Machines Scale Sets (VMSS)
• Azure Container Instance (ACI)

在将系统托管标识分配给你的 Azure 资源后，你将获得类似以下的凭据：

{
    "principalId": "<object-id>",
    "tenantId": "<tenant-id>",
    "type": "SystemAssigned",
    "userAssignedIdentities": null
}

从返回的值中，请注意 principalId 值，这是为你的标识创建的服务主体 ID。使用该值授予你的 Azure 资源组件访问该标识的权限。

在组件中设置标识

默认情况下，Dapr Azure 组件会查找其运行环境的系统托管标识并以此身份进行身份验证。通常，对于给定组件，除了服务名称、存储帐户名称以及 Azure 服务所需的任何其他属性（在文档中列出）之外，使用系统托管标识不需要其他必需属性。

对于用户分配标识，除了所使用服务所需的基本属性外，你还需要在组件中指定 azureClientId（用户分配标识 ID）。确保用户分配标识已附加到运行 Dapr 的 Azure 服务上，否则你将无法使用该标识。

以下示例演示如何在 Azure KeyVault secrets 组件中设置系统托管标识或用户分配标识。

• 系统托管
• 用户分配
• Kubernetes

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: mykeyvault

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: mykeyvault
  - name: azureClientId
    value: someAzureIdentityClientIDHere

故障排除

如果你收到错误或托管标识未按预期工作，请检查以下项目是否为真：

• 系统托管标识或用户分配标识在目标资源上没有所需的权限。

• 用户分配标识未附加到正在加载组件的 Azure 服务（容器应用或 Pod）。这种情况特别可能发生在：

  • 你有一个未限定范围的组件（一个由环境中所有容器应用或 AKS 集群中所有部署加载的组件）。
  • 你只将用户分配标识附加到一个容器应用或 AKS 中的一个部署（使用 Azure Workload Identity）。

  在此场景中，由于标识未附加到 AKS 中的每个其他容器应用或部署，因此通过 azureClientId 引用用户分配标识的组件会失败。

最佳实践： 使用用户分配标识时，请务必将组件范围限定到特定应用！

后续步骤

2 - Azure API Management 的 Dapr 集成策略

Azure API Management 是为后端服务（包括使用 Dapr 构建的服务）创建一致且现代化的 API 网关的一种方式。你可以在自托管的 API Management 网关中启用 Dapr 支持，以允许它们：

• 将请求转发到 Dapr 服务
• 向 Dapr 发布订阅主题发送消息
• 触发 Dapr 输出绑定

试一试 Dapr 与 Azure API Management 集成示例。

3 - Dapr extension for Azure Functions runtime

Dapr 通过一个扩展与 Azure Functions runtime 集成，使函数能够与 Dapr 无缝交互。

• Azure Functions 提供事件驱动的编程模型。
• Dapr 提供云原生构建块。

该扩展将两者结合，用于无服务器和事件驱动应用。

4 - 适用于 Azure Kubernetes Service (AKS) 的 Dapr 扩展

在 AKS 上安装 Dapr 的推荐方法是使用 AKS Dapr 扩展。该扩展提供以下功能：

• 通过 Azure CLI 命令行参数支持所有原生 Dapr 配置功能
• 可选择启用 Dapr 运行时的自动次版本升级

使用 AKS 的 Dapr 扩展的前提条件：

• Azure 订阅
• 最新版本的 Azure CLI
• 现有的 AKS 集群
• Azure Kubernetes Service RBAC 管理员角色