工作负载身份联合概念

了解工作负载身份联合如何实现对Microsoft Entra受保护资源的安全访问，而无需管理密钥或机密。 本文概述了其优点和支持的方案。

可以在以下场景中使用工作负荷身份联合：GitHub Actions、运行在 Kubernetes 上的工作负荷，或运行在非 Azure 平台的计算工作负荷。

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

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

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

支持的方案

以下情境支持通过工作负载身份联合来访问 Microsoft Entra 受保护的资源：

• 在任何 Kubernetes 群集（Azure Kubernetes Service (AKS)、Amazon Web Services EKS、Google Kubernetes 引擎（GKE）或本地上运行的工作负荷。 在 Microsoft Entra ID 中，用户分配的托管身份或应用与 Kubernetes 工作负载（如 工作负载身份概述中所述）之间建立信任关系。
• GitHub Actions。 首先，在 Microsoft Entra ID 中配置 用户分配的托管标识或 应用，并在 Microsoft Entra 管理中心或使用 Microsoft Graph 与 GitHub 存储库之间建立信任关系。 然后配置GitHub Actions工作流从Microsoft标识提供者获取访问令牌并访问Azure资源。
• 使用应用标识在Azure计算平台上运行的工作负荷。 首先将用户分配的托管标识分配给Azure VM 或应用服务。 然后，配置应用与用户分配的标识之间的信任关系。
• 在 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 Resource Manager服务连接。

工作原理

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

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

在所有情况下，将外部令牌兑换为访问令牌的工作流都是相同的。 下图展示了一般的工作流程，其中工作负荷将外部令牌交换为访问令牌，然后访问Microsoft Entra的受保护资源。

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 App Service。

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

另请参阅

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