Spring Cloud Azure 身份验证

项目
12/21/2024

本文 适用于：✅ 版本 4.19.0 ✅ 版本 5.19.0

本文介绍所有 Spring Cloud Azure 身份验证方法。

DefaultAzureCredential

DefaultAzureCredential 适用于在 Azure 云中运行应用程序的大多数方案。这是因为 DefaultAzureCredential 将通常用于在开发环境中进行身份验证的凭据与用于进行身份验证的凭据组合在一起。

注意

DefaultAzureCredential 旨在通过处理具有合理默认行为的常见方案来简化 SDK 入门。如果想要更多控制或方案未由默认设置提供，则应使用其他凭据类型。

DefaultAzureCredential 将尝试通过以下机制进行身份验证：

关系图，显示“DefaultAzureCredential”的身份验证机制。

环境 - DefaultAzureCredential 将读取通过环境变量指定的帐户信息，并使用它进行身份验证。
托管标识 - 如果应用程序部署到启用了托管标识的 Azure 主机，DefaultAzureCredential 将使用该帐户进行身份验证。
IntelliJ - 如果已通过用于 IntelliJ 的 Azure 工具包进行身份验证，DefaultAzureCredential 将使用该帐户进行身份验证。
Visual Studio Code - 如果已通过 Visual Studio Code Azure 帐户插件进行身份验证，DefaultAzureCredential 将使用该帐户进行身份验证。
Azure CLI - 如果已通过 Azure CLI az login 命令对帐户进行身份验证，DefaultAzureCredential 将使用该帐户进行身份验证。

提示

请确保已向安全主体授予足够的权限来访问 Azure 资源。有关详细信息，请参阅使用 Microsoft Entra ID授权访问。

注意

由于 Spring Cloud Azure AutoConfigure 4.1.0，因此默认会自动注册名为 springCloudAzureCredentialTaskExecutor 的 ThreadPoolTaskExecutor bean，并管理 Azure 标识创建的所有线程。此线程池管理的每个线程的名称以 az-identity-为前缀。这种 ThreadPoolTaskExecutor 豆独立于 Spring Boot 提供的 Executor 豆。

托管标识

常见的挑战是管理用于保护构成解决方案的不同组件之间的通信的机密和凭据。托管标识无需管理凭据。托管标识为连接到支持Microsoft Entra 身份验证的资源时要使用的应用程序提供标识。应用程序可以使用托管标识来获取Microsoft Entra 令牌。例如，应用程序可以使用托管标识访问 Azure Key Vault 等资源，可以在其中以安全方式存储凭据或访问存储帐户。

我们鼓励在应用程序中使用托管标识，而不是在应用程序中使用连接字符串或密钥，因为它更安全，并且会节省管理机密和凭据的麻烦。在这种情况下，DefaultAzureCredential 可以更好地使用本地存储的帐户信息在本地开发方案，然后将应用程序部署到 Azure 云并使用托管标识。

托管标识类型

有两种类型的托管标识：

系统分配 - 某些 Azure 服务允许直接在服务实例上启用托管标识。启用系统分配的托管标识时，Microsoft Entra 中创建一个标识，该标识绑定到该服务实例的生命周期。因此，删除资源后，Azure 会自动删除标识。根据设计，只有 Azure 资源才能使用此标识从 Microsoft Entra ID 请求令牌。
用户分配 - 还可以创建托管标识作为独立的 Azure 资源。可以创建用户分配的托管标识，并将其分配给 Azure 服务的一个或多个实例。使用用户分配的托管标识，该标识独立于使用它的资源进行管理。

注意

使用用户分配的托管标识时，可以通过 spring.cloud.azure.credential.client-id 或 spring.cloud.azure.<azure-service>.credential.client-id指定客户端 ID。如果使用系统分配的托管标识，则不需要凭据配置。

提示

请确保已向安全主体授予足够的权限来访问 Azure 资源。有关详细信息，请参阅使用 Microsoft Entra ID授权访问。

有关托管标识的详细信息，请参阅什么是 Azure 资源的托管标识？。

其他凭据类型

如果需要更多控制，或者方案未由 DefaultAzureCredential 或默认设置提供，则应使用其他凭据类型。

使用 Microsoft Entra ID 进行身份验证和授权

使用 Microsoft Entra ID，可以使用 Azure 基于角色的访问控制（Azure RBAC）向安全主体（可能是用户或应用程序服务主体）授予权限。当安全主体（用户或应用程序）尝试访问 Azure 资源（例如事件中心资源）时，必须授权请求。使用 Microsoft Entra ID 时，访问资源的过程分为两个步骤：

首先，对安全主体的标识进行身份验证，并返回 OAuth 2.0 令牌。
接下来，令牌作为请求的一部分传递给 Azure 服务，以授权访问指定的资源。

使用 Microsoft Entra ID 进行身份验证

若要将应用程序连接到支持 Microsoft Entra 身份验证的资源，可以使用前缀 spring.cloud.azure.credential 或 spring.cloud.azure.<azure-service>.credential 设置以下配置

下表列出了身份验证属性：

财产	描述
client-id	使用 Azure 执行服务主体身份验证时要使用的客户端 ID。
client-secret	使用 Azure 执行服务主体身份验证时要使用的客户端密码。
client-certificate-path	使用 Azure 执行服务主体身份验证时要使用的 PEM 证书文件的路径。
client-certificate-password	证书文件的密码。
username	在 Azure 中执行用户名/密码身份验证时要使用的用户名。
密码	在 Azure 中执行用户名/密码身份验证时要使用的密码。
已启用 managed-identity-enabled	是否启用托管标识。

提示

有关所有 Spring Cloud Azure 配置属性的列表，请参阅 Spring Cloud Azure 配置属性。

应用程序将在多个位置查找可用的凭据，如果未配置凭据属性，将使用 DefaultAzureCredential。若要使用特定凭据，请参阅以下示例以获取指导。

以下示例演示如何使用系统分配的托管标识进行身份验证：

spring.cloud.azure:
  credential:
    managed-identity-enabled: true

以下示例演示如何使用用户分配的托管标识进行身份验证：

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
    client-id: ${AZURE_CLIENT_ID}

以下示例演示如何对客户端机密使用服务主体进行身份验证：

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-secret: ${AZURE_CLIENT_SECRET}
  profile:
    tenant-id: <tenant>

注意

允许 tenant-id 的值包括：common、organizations、consumers或租户 ID。有关这些值的详细信息，请参阅使用错误的终结点（个人和组织帐户）错误AADSTS50020 - 租户中不存在来自标识提供者的用户帐户。有关转换单租户应用的信息，请参阅在 Microsoft Entra ID上将单租户应用转换为多租户。

以下示例演示如何对客户端 PFX 证书使用服务主体进行身份验证：

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
    client-certificate-password: ${AZURE_CLIENT_CERTIFICATE_PASSWORD}
  profile:
    tenant-id: <tenant>

注意

以下示例演示如何对客户端 PEM 证书使用服务主体进行身份验证：

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
  profile:
    tenant-id: <tenant>

注意

以下示例演示如何使用用户凭据进行身份验证：

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    username: ${AZURE_USER_USERNAME}
    password: ${AZURE_USER_PASSWORD}

以下示例演示如何使用不同的服务主体通过 Key Vault 进行身份验证。此示例使用两个凭据配置应用程序：一个系统分配的托管标识和一个服务主体。 Key Vault 机密客户端将使用服务主体，但任何其他组件将改用托管标识。

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
  keyvault.secret:
    credential:
      client-id: ${AZURE_CLIENT_ID}
      client-secret: ${AZURE_CLIENT_SECRET}
    profile:
      tenant-id: <tenant>

注意

使用 Microsoft Entra ID 授予访问权限

授权步骤要求向安全主体分配一个或多个 Azure 角色。分配给安全主体的角色确定主体将拥有的权限。

提示

有关所有 Azure 内置角色的列表，请参阅 Azure 内置角色。

下表列出了用于授权访问 Spring Cloud Azure 中支持的 Azure 服务的 Azure 内置角色：

角色	描述
应用配置数据所有者	允许完全访问应用配置数据。
应用配置数据读取器	允许读取对应用配置数据的访问权限。
Azure 事件中心数据所有者	允许完全访问 Azure 事件中心资源。
Azure 事件中心数据接收器	允许接收对 Azure 事件中心资源的访问。
Azure 事件中心数据发送方	允许发送对 Azure 事件中心资源的访问。
Azure 服务总线数据所有者	允许完全访问 Azure 服务总线资源。
Azure 服务总线数据接收器	允许接收对 Azure 服务总线资源的访问。
Azure 服务总线数据发送方	允许发送对 Azure 服务总线资源的访问。
存储 Blob 数据所有者	提供对 Azure 存储 Blob 容器和数据的完整访问权限，包括分配 POSIX 访问控制。
存储 Blob 数据读取器	读取和列出 Azure 存储容器和 Blob。
存储队列数据读取器	读取和列出 Azure 存储队列和队列消息。
Redis 缓存参与者	管理 Redis 缓存。

注意

使用 Spring Cloud Azure 资源管理器获取事件中心、服务总线和存储队列的连接字符串或 Redis 缓存的属性时，请分配 Azure 内置角色 Contributor。 Azure Redis 缓存很特别，还可以分配 Redis Cache Contributor 角色来获取 Redis 属性。

注意

Key Vault 访问策略确定给定的安全主体（即用户、应用程序或用户组）是否可以对 Key Vault 机密、密钥和证书执行不同的操作。可以使用 Azure 门户、Azure CLI 或 Azure PowerShell 分配访问策略。有关详细信息，请参阅分配 Key Vault 访问策略。

重要

Azure Cosmos DB 公开两个内置角色定义：Cosmos DB Built-in Data Reader 和 Cosmos DB Built-in Data Contributor。但是，Azure 门户对角色管理的支持尚不可用。有关权限模型、角色定义和角色分配的详细信息，请参阅使用 Azure Cosmos DB 帐户的 Microsoft Entra ID 配置基于角色的访问控制。

SAS 令牌

还可以配置服务以使用共享访问签名（SAS）进行身份验证。 spring.cloud.azure.<azure-service>.sas-token 是要配置的属性。例如，使用 spring.cloud.azure.storage.blob.sas-token 对存储 Blob 服务进行身份验证。

连接字符串

某些 Azure 服务支持连接字符串，以提供连接信息和凭据。若要使用连接字符串连接到这些 Azure 服务，只需配置 spring.cloud.azure.<azure-service>.connection-string。例如，将 spring.cloud.azure.eventhubs.connection-string 配置为连接到事件中心服务。

通过