Azure 集成

• 1: Azure 身份验证
• 1.1: Azure 身份验证
• 1.2: 如何创建新的 Microsoft Entra ID 应用程序和服务主体
• 1.3: 如何使用托管身份
• 2: Azure API Management 与 Dapr 的集成策略
• 3: Azure Functions 运行时的 Dapr 扩展
• 4: 适用于 Azure Kubernetes Service (AKS) 的 Dapr 扩展

1 - Azure 身份验证

1.1 - Azure 身份验证

大多数 Dapr 的 Azure 组件支持使用 Microsoft Entra ID 进行身份验证。通过这种方式：

• 管理员可以充分利用 Azure 基于角色的访问控制 (RBAC) 的精细权限。
• 在 Azure 服务（如 Azure 容器应用、Azure Kubernetes 服务、Azure 虚拟机或其他 Azure 平台服务）上运行的应用程序可以使用 托管身份 (MI) 和 工作负载身份。这些功能使您的应用程序能够在不需要管理敏感凭据的情况下进行身份验证。

关于 Microsoft Entra ID 的身份验证

Microsoft Entra ID 是 Azure 的身份和访问管理 (IAM) 解决方案，用于对用户和服务进行身份验证和授权。

Microsoft Entra ID 基于 OAuth 2.0 等开放标准，允许服务（应用程序）获取访问令牌以请求 Azure 服务，包括 Azure 存储、Azure 服务总线、Azure 密钥保管库、Azure Cosmos DB、Azure PostgreSQL 数据库、Azure SQL 等。

在 Azure 术语中，应用程序也被称为“服务主体”。

一些 Azure 组件提供其他身份验证方法，例如基于“共享密钥”或“访问令牌”的系统。尽管这些方法在 Dapr 中是有效且受支持的，但建议尽可能使用 Microsoft Entra ID 对 Dapr 组件进行身份验证，以利用其众多优势，包括：

• 托管身份和工作负载身份
• 基于角色的访问控制
• 审计
• （可选）使用证书进行身份验证

托管身份和工作负载身份

使用托管身份 (MI)，您的应用程序可以通过 Microsoft Entra ID 进行身份验证并获取访问令牌以请求 Azure 服务。当您的应用程序在支持的 Azure 服务（如 Azure 虚拟机、Azure 容器应用、Azure Web 应用等）上运行时，可以在基础设施级别为您的应用程序分配一个身份。

使用 MI 后，您的代码无需处理凭据，这样可以：

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

在 Azure Kubernetes 服务上运行的应用程序可以类似地利用 工作负载身份 自动为单个 pod 提供身份。

基于角色的访问控制

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

审计

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

（可选）使用证书进行身份验证

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

对其他 Azure 环境的支持

默认情况下，Dapr 组件配置为与“公共云”中的 Azure 资源交互。如果您的应用程序部署到其他云（如 Azure 中国或 Azure 政府“主权云”），您可以通过将 azureEnvironment 元数据属性设置为以下支持的值之一来启用该功能：

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

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

凭据元数据字段

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

元数据选项

根据您向 Dapr 服务传递凭据的方式，您有多种元数据选项。

• 关于 Microsoft Entra ID 的身份验证
  • 托管身份和工作负载身份
  • 基于角色的访问控制
  • 审计
  • （可选）使用证书进行身份验证
• 对其他 Azure 环境的支持
• 凭据元数据字段
  • 元数据选项
    • 使用客户端凭据进行身份验证
    • 使用证书进行身份验证
    • 使用托管身份 (MI) 进行身份验证
    • 在 AKS 上使用工作负载身份进行身份验证
    • 使用 Azure CLI 凭据进行身份验证（仅限开发）
  • 在 Dapr 组件中的示例用法
• 下一步
• 参考资料

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

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

使用证书进行身份验证

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

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

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

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

在 Azure Kubernetes 服务 (AKS) 上运行时，您可以使用工作负载身份对组件进行身份验证。请参阅 Azure AKS 文档以了解如何为您的 Kubernetes 资源 启用工作负载身份。

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

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

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

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

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

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

在 Dapr 组件中的示例用法

在此示例中，您将设置一个使用 Microsoft Entra ID 进行身份验证的 Azure 密钥保管库 secret 存储组件。

• 自托管
• 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) 概述
• Secrets 构建块
• 操作指南：检索 secret
• 操作指南：在 Dapr 组件中引用 secret
• Secrets API 参考

1.2 - 如何创建新的 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)

选择传递凭据的方式。

• 客户端密钥
• PFX 证书

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 "服务主体 ID: ${SERVICE_PRINCIPAL_ID}"

预期输出：

服务主体 ID: 1d0ccf05-5427-4b5e-8eb4-005ac5f9f163

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

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

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

下一步

1.3 - 如何使用托管身份

托管身份可以自动进行身份验证，因为您的应用程序运行在具有系统分配或用户分配身份的 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 工作负载身份）。

  在这种情况下，由于身份未附加到 AKS 中的每个其他容器应用或部署，引用用户分配身份的组件通过 azureClientId 失败。

最佳实践： 使用用户分配身份时，请确保将您的组件范围限定在特定应用上！

下一步

2 - Azure API Management 与 Dapr 的集成策略

Azure API Management 是一种用于为后端服务创建一致且现代的 API 网关的方法，其中也包括使用 Dapr 构建的服务。您可以在自托管的 API Management 网关中启用 Dapr 支持，从而实现以下功能：

• 将请求转发至 Dapr 服务
• 向 Dapr 发布/订阅主题发送消息
• 激活 Dapr 输出绑定

试用 Dapr & Azure API Management 集成示例。

3 - Azure Functions 运行时的 Dapr 扩展

Dapr 通过一个扩展与 Azure Functions 运行时 集成，使函数能够轻松地与 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 管理员角色