通过

工作负荷联合身份验证

  • 项目

本文概述了适用于软件工作负载的工作负载联合身份验证。 使用工作负载标识联合，可以访问受 Microsoft Entra 保护的资源，而无需管理机密（适用于支持的方案）。

可以在 GitHub Actions、Kubernetes 上运行的工作负载或 Azure 外部计算平台中运行的工作负载等方案中使用工作负载联合身份验证。

为什么使用工作负载联合身份验证？

观看此视频，了解使用工作负载标识联合的原因。

通常，软件工作负载（例如应用程序、服务、脚本或基于容器的应用程序）需要一个标识来验证和访问资源或与其他服务通信。 当这些工作负载在 Azure 上运行时，你可以使用托管标识，Azure 平台会为你管理凭据。 但是，对于在 Azure 中运行的软件工作负载，你只能使用托管标识。 对于在 Azure 外部运行的软件工作负载，则需要使用应用程序凭据（机密或证书）访问受 Microsoft Entra 保护的资源（例如 Azure、Microsoft Graph、Microsoft 365 或第三方资源）。 这些凭据会带来安全风险，必须安全存储并定期轮换。 如果凭据过期，还会面临服务停机的风险。

使用工作负载标识联合将 Microsoft Entra ID 中的用户分配的托管标识或应用注册配置为信任来自外部标识提供者 (IdP)（例如 GitHub 或 Google）的令牌。 Microsoft Entra ID 中的用户分配的托管标识或应用注册将成为诸如在本地 Kubernetes 或 GitHub Actions 工作流中运行的软件工作负载的标识。 创建该信任关系后，外部软件工作负载便可以使用来自外部 IdP 的受信任令牌交换来自 Microsoft 标识平台的访问令牌。 然后，软件工作负载将使用该访问令牌来访问自身已获得访问权限的受 Microsoft Entra 保护的资源。 这省去了手动管理凭据的维护负担，并消除了泄露机密或证书过期的风险。

支持的方案

以下方案支持使用工作负载标识联合访问受 Microsoft Entra 保护的资源：

  • 在任何 Kubernetes 群集（Azure Kubernetes 服务 [AKS]、Amazon Web Services EKS、Google Kubernetes Engine [GKE] 或本地）上运行的工作负载。 在 Microsoft Entra ID 中的用户分配的托管标识或应用与 Kubernetes 工作负载之间建立信任关系（在工作负载标识概述中进行了介绍）。
  • GitHub Actions。 首先，在 Microsoft Entra ID 中的用户分配的托管标识或应用程序与 Microsoft Entra 管理中心中的 GitHub 存储库之间配置信任关系，或使用 Microsoft Graph 配置信任关系。 然后配置 GitHub Actions 工作流以从 Microsoft 标识提供者获取访问令牌并访问 Azure 资源。
  • Google Cloud。 首先，在 Microsoft Entra ID 中的用户分配的托管标识或应用与 Google Cloud 中的标识之间配置信任关系。 然后配置在 Google Cloud 中运行的软件工作负载，以从 Microsoft 标识提供者获取访问令牌并访问受 Microsoft Entra 保护的资源。 请参阅从 Google Cloud 中的应用访问受 Microsoft Entra 保护的资源。
  • 在 Amazon Web Services (AWS) 中运行的工作负载。 首先，在 Microsoft Entra ID 中的用户分配的托管标识或应用与 Amazon Cognito 中的标识之间配置信任关系。 然后，将在 AWS 中运行的软件工作负载配置为从 Microsoft 标识提供者获取访问令牌并访问受 Microsoft Entra 保护的资源。 请参阅使用 AWS 时的工作负载联合身份验证。
  • 在 Azure 之外的计算平台中运行的其他工作负载。 在 Microsoft Entra ID 中的用户分配的托管标识或应用程序与计算平台的外部 IdP 之间配置信任关系。 可以使用该平台颁发的令牌向 Microsoft 标识平台进行身份验证并调用 Microsoft 生态系统中的 API。 使用客户端凭据流从 Microsoft 标识平台获取访问令牌，传入标识提供者的 JWT，而不是使用存储的证书自行创建。
  • SPIFFE 和 SPIRE 是一组与平台无关的开源标准，用于为在各种平台和云供应商服务上部署的软件工作负载提供标识。 首先，在 Microsoft Entra ID 中的用户分配的托管标识或应用与外部工作负载的 SPIFFE ID 之间配置信任关系。 然后，将外部软件工作负载配置为从 Microsoft 标识提供者获取访问令牌并访问受 Microsoft Entra 保护的资源。 请参阅使用 SPIFFE 和 SPIRE 时的工作负载联合身份验证。
  • 在 Azure Pipelines 中创建新的服务连接（预览版）。 使用工作负载标识联合创建 Azure 资源管理器服务连接。

注意

Microsoft Entra ID 颁发的令牌不能用于联合标识流。 联合标识凭据流不支持 Microsoft Entra ID 颁发的令牌。

工作原理

在外部 IdP 与 Microsoft Entra ID 中的用户分配的托管标识或应用程序之间创建信任关系。 联合标识凭据用于指示应用程序或托管标识应该信任来自外部 IdP 的哪个令牌。 可以通过下列方式之一配置联合标识：

  • 通过 Microsoft Entra 管理中心、Azure CLI、Azure PowerShell、Azure SDK 和 Azure 资源管理器 (ARM) 模板，在用户分配的托管标识上。 外部工作负载使用访问令牌来访问 Microsoft Entra 受保护的资源，而无需管理机密（在支持的场景中）。 配置信任关系的步骤会有所不同，具体取决于方案和外部 IdP。
  • 在 Microsoft Entra管理中心中的应用注册上或通过 Microsoft Graph。 此配置允许你获取应用程序的访问令牌，而无需管理 Azure 外部的机密。 有关详细信息，请了解如何将应用配置为信任外部标识提供者。

注意

联合标识凭据 issuer、subject 和 audience 值必须与外部 IdP 要发送到 Microsoft Entra ID 的令牌中包含的对应 issuer、subject 和 audience 值匹配，并且大小写也必须匹配，才能授权应用场景。 若要详细了解此更改，请访问身份验证的新增功能。

但是，所有方案用于将外部令牌交换为访问令牌的工作流都是相同的。 下图显示了工作负载用外部令牌交换访问令牌，然后访问受 Microsoft Entra 保护资源的常规工作流。

显示一个外部令牌交换为一个访问令牌并访问 Azure 的示意图

  1. 外部工作负载（例如 GitHub Actions 工作流）从外部 IdP（例如 GitHub）请求令牌。
  2. 外部 IdP 向外部工作负载颁发令牌。
  3. 外部工作负载（例如 GitHub 工作流中的登录操作）将令牌发送到 Microsoft 标识平台并请求访问令牌。
  4. Microsoft 标识平台会检查用户分配的托管标识或应用注册上的信任关系，并根据外部 IdP 上的 OpenID Connect (OIDC) 颁发者 URL 验证外部令牌。
  5. 满足检查条件后，Microsoft 标识平台向外部工作负载颁发访问令牌。
  6. 外部工作负载使用来自 Microsoft 标识平台的访问令牌访问受 Microsoft Entra 保护的资源。 例如，GitHub Actions 工作流使用访问令牌将 Web 应用发布到 Azure 应用服务。

从外部 IdP 的 OIDC 终结点下载签名密钥时，Microsoft 标识平台只会存储前 100 个签名密钥。 如果外部 IdP 公开了 100 个以上的签名密钥，则使用工作负载联合身份验证时可能会出错。

后续步骤

详细了解工作负载联合身份验证的工作原理：

  • 如何在用户分配的托管标识上创建、删除、获取或更新联合标识凭据。
  • 如何在应用注册中创建、删除、获取或更新联合标识凭据。
  • 阅读工作负载标识概述，了解如何配置 Kubernetes 工作负载，以便从 Microsoft 标识提供者获取访问令牌并访问受 Microsoft Entra 保护的资源。
  • 阅读 GitHub Actions 文档，详细了解如何配置 GitHub Actions 工作流，以便从 Microsoft 标识提供者获取访问令牌并访问受 Microsoft Entra 保护的资源。
  • Microsoft Entra ID 如何使用 OAuth 2.0 客户端凭据授予和另一个 IdP 颁发的客户端断言来获取令牌。
  • 有关由外部标识提供者创建的 JWT 所需格式的信息，请阅读断言格式。