使用托管式工作负载身份的后端 mTLS 概览

本文档简要介绍了如何使用托管式工作负载身份在应用负载均衡器与其后端之间实现双向 TLS (mTLS)。托管式工作负载身份会自动预配和管理来自 Certificate Authority Service 的 X.509 证书。

您也可以在不使用托管式工作负载身份的情况下实现后端 mTLS。如需详细了解不使用托管式工作负载身份的后端 mTLS，请参阅后端经过身份验证的 TLS 和后端 mTLS 概览。

可以在以下负载均衡器的后端服务资源上配置托管式工作负载身份：

• 全球外部应用负载均衡器
• 区域外部应用负载均衡器
• 跨区域内部应用负载均衡器
• 区域级内部应用负载均衡器

本文档中的信息基于以下文档中介绍的概念：

• 托管式工作负载身份概览
• Secure Production Identity Framework For Everyone (SPIFFE)
• Certificate Authority Service
• 后端验证的 TLS 和后端 mTLS 概览

负载均衡器的托管式工作负载身份简介

如果没有托管式工作负载身份，则设置后端 mTLS 需要配置多个资源。当您将托管式身份分配给负载均衡器的后端服务时，托管式工作负载身份会自动为 mTLS 创建必要的资源，例如客户端证书、信任配置和后端身份验证配置。

对于后端 mTLS，负载均衡器的后端服务资源充当来源工作负载，向后端（即目标工作负载）验证自身身份。

您可以为负载均衡器的后端服务分配一个托管式身份（由 SPIFFE ID 表示）。Google Cloud Certificate Authority Service 会自动为 SPIFFE ID 预配 X.509 证书。SPIFFE ID 的此 X.509 证书也称为 SPIFFE 可验证身份文档 (SVID)。负载均衡器的后端服务及其后端使用 SVID 通过 mTLS 身份验证相互进行身份验证。

下图展示了负载均衡器（来源工作负载）和后端（目标工作负载）使用托管式工作负载身份相互进行身份验证。

使用托管式工作负载身份的后端 mTLS（点击可放大）。

以下是 X.509-SVID 的示例，它充当 SPIFFE ID 的封装容器。SPIFFE ID（表示为 URI）在 X.509 证书的主题备用名称 (SAN) 中进行编码。

Issuer:
    C=US
    O=Example Inc.
    CN=Example CA

Validity:
    Not Before: Jun 14 00:00:00 2025 GMT
    Not After : Jun 16 00:00:00 2025 GMT

Subject (Distinguished Name):
    C=US
    O=Example Inc.
    OU=Production
    CN=api.example.com

Subject Public Key Info:
    Public Key Algorithm: RSA Encryption
    RSA Public-Key: (2048 bit)

X.509v3 Extensions:
    Subject Alternative Name (SAN):
        DNS: api.example.com
        URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

此输出包括以下值：

• WORKLOAD_IDENTITY_POOL_ID：工作负载身份池 ID
• PROJECT_NUMBER：您的Google Cloud 项目的项目编号
• NAMESPACE_ID：命名空间 ID
• MANAGED_IDENTITY_ID：托管式身份 ID

使用托管式工作负载身份的好处

以下是将托管式工作负载身份用于后端 mTLS 的一些优势：

• 增强的安全性：通过加入工作负载身份池， Google Cloud 负载均衡器及其后端会成为信任域的一部分。与后端 mTLS 结合使用时，负载均衡器和后端工作负载会相互进行身份验证。这种双向身份验证可防止未经授权的工作负载访问您的服务，并对传输中的数据进行加密。

• 自动证书管理：工作负载证明成功后，Google Cloud 会自动为参与工作负载身份池信任域的工作负载预配和轮替 X.509 证书。这种 X.509 证书的自动管理功能消除了复杂且容易出错的手动证书管理流程。

• 可互操作的身份：工作负载身份池使用 SPIFFE 框架，这是一种用于跨分布式系统管理身份的标准，可在基于微服务的现代架构中实现身份验证和授权。

• 集中治理：工作负载身份池提供了一个集中控制点。管理员可以定义信任域并建立证明政策，以控制哪些工作负载可以接收托管式身份的 X.509 证书。

证书要求

配置证书时，请确保它们符合以下要求：

• 现代加密工具构成了 mTLS 身份验证的基础。证书必须使用 RSA 或 ECDSA 算法进行密钥交换。哈希算法必须使用 SHA-256 或更强的加密哈希函数。不支持 MD4、MD5 和 SHA-1 等哈希算法。

• 后端提供的服务器叶证书具有以下要求：

  • 基本限制条件扩展程序不得包含 CA=true。
  • 扩展密钥用途扩展程序必须包含 serverAuth。
  • 扩展密钥用途扩展程序不得包含 codeSigning、timeStamping 或 OCSPSigning 字段。
  • 该证书不得过期。

• 后端 mTLS 中使用的叶客户端（负载均衡器）证书是自动创建的 Certificate Manager 托管式身份证书，应自动满足以下要求：

  • 基本限制条件扩展程序不得包含 CA=true。
  • 扩展密钥用途扩展程序必须包含 clientAuth。
  • 扩展密钥用途扩展程序不得包含 codeSigning、timeStamping 或 OCSPSigning 字段。
  • 该证书不得过期。

• 如需对后端向负载均衡器提供的服务器证书进行身份验证，信任配置中的根证书和中间证书必须满足以下要求：

  • 基本限制条件扩展程序必须包含 CA=true。
  • 密钥用途扩展程序必须设置为 keyCertSign。
  • 扩展密钥用途扩展程序必须包含 serverAuth 字段。
  • 该证书不得过期。

使用托管式工作负载身份的后端 mTLS 的架构

以下组件协同工作，以使用托管式工作负载身份实现后端 mTLS：

• 负载均衡器的后端服务 (Compute Engine API)
• Identity and Access Management 信任域 (Identity and Access Management API)
• 证书授权机构池 (Certificate Authority Service API)
• 后端身份验证配置 (网络安全 API)
• Certificate Manager 信任配置 (Certificate Manager API)
• Certificate Manager 托管式身份证书 (Certificate Manager API)

下图展示了负载均衡器后端服务上的代管式身份，该身份可让负载均衡器向后端验证自己的身份。在图中，第 1-3 步表示显式创建的资源，而第 4-5 步表示自动创建的资源。

1. 配置 Certificate Authority Service CA 池，以便向托管式工作负载身份颁发证书。
2. 通过创建工作负载身份池来配置信任域。 此池需要命名空间、代管式身份、证明政策、内嵌证书颁发配置资源和内嵌信任配置资源。
3. 使用托管式身份配置负载均衡器的后端服务。

4. 托管式工作负载身份会自动创建 Certificate Manager 托管式身份证书和 Certificate Manager 信任配置。

   Certificate Manager 托管式身份证书是根据工作负载身份池中的证书颁发配置创建的。Certificate Manager 信任配置与工作负载身份池的内嵌信任配置保持同步。

5. 托管式工作负载身份会自动创建后端身份验证配置。

   Certificate Manager 信任配置已附加到后端身份验证配置。Certificate Manager 托管式身份证书 (X.509-SVID) 也会附加到后端身份验证配置，然后用于向后端进行身份验证。

如需详细了解如何使用托管式身份配置后端 mTLS，请参阅使用托管式工作负载身份设置后端 mTLS。

使用托管式工作负载身份的后端 mTLS 架构（点击可放大）。

使用托管式身份在后端 mTLS 期间创建的资源

如上图所示，在为后端服务分配代管式身份时，您无需配置后端身份验证配置、Certificate Manager 信任配置和 Certificate Manager 证书。这些资源由托管式工作负载身份自动创建。

本部分将详细介绍托管式身份配置流程的不同部分，重点介绍显式创建的资源和自动创建的资源。

显式创建的资源

使用托管式工作负载身份配置后端 mTLS 时，需要明确创建以下资源。

证书授权机构池

如需为负载均衡器配置托管式工作负载身份，您首先需要配置一个证书授权机构，并视需要配置一个或多个从属 CA。此设置称为 CA 层次结构。您可以使用 CA Service 池来设置此层次结构。

请注意以下 CA 池位置要求：

• 对于全球后端服务，CA 池可以位于任何区域，因为没有全球 CA 池。
• 对于区域级后端服务，CA 池必须与后端服务位于同一区域。

通过使用内嵌证书颁发配置更新工作负载身份池，将工作负载身份池绑定到 CA 池，该配置会将每个 Google Cloud 区域映射到同一区域中的 CA 池。

工作负载身份池

托管式工作负载身份在工作负载身份池中定义，该池充当信任域。

信任域代表一个逻辑安全边界，工作负载可以在该边界内使用其 SPIFFE ID 相互进行身份验证和授权。同一信任域中的所有工作负载都共享一个共同的信任根，这使工作负载能够验证彼此的身份。

如需使用托管式身份，您需要在 TRUST_DOMAIN 模式下配置工作负载身份池。池中的所有身份都由单个命名空间和单个工作负载标识符组成。

命名空间

在工作负载身份池中，托管式工作负载身份被整理到称为“命名空间”的管理边界中。命名空间可帮助您整理和授予对相关 Workload Identity 的访问权限。

托管式工作负载身份

托管式工作负载身份基于 SPIFFE 标准，该标准提供了一个框架，用于使用唯一的 SPIFFE ID 识别和保护工作负载之间的通信并向其进行身份验证。

托管式工作负载身份或托管式身份是在工作负载身份池中配置的工作负载标识符。它会附加到Google Cloud 资源。每个代管式身份都由命名空间和单个工作负载标识符唯一标识。

在实现后端 mTLS 的上下文中，代管式身份会附加到负载均衡器的后端服务资源。

托管式身份的值是完全指定的 SPIFFE ID，必须符合以下格式：

spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

TRUST_DOMAIN_NAME 会进一步展开，如下所示：

WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog

总而言之，Compute Engine 工作负载（例如负载均衡器的后端服务资源）可以具有如下托管式身份：

spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

注意：spiffe 前缀不用于后端服务 (backendService.tlsSettings.identity) 的 identity 字段。但是，当 spiffe 前缀在 X.509 证书的主体备用名称 (SAN) 中表示为 URI 时，会使用该前缀。

证明政策

证明政策包含 Google Cloud IAM 用于验证后端服务是否有资格接收托管式身份的 X.509 证书的规则。

如果证明政策验证通过，IAM 会向 Certificate Authority Service 请求托管式身份的 X.509 证书。X.509 证书是在绑定到代管式身份的 CA 池中创建的。CA Service 通过身份反映预配证书，其中配置的 SPIFFE ID 会反映到 X.509 证书上。

内嵌证书颁发配置

设置工作负载身份池时，您需要配置内嵌证书颁发配置。此配置指定使用 Certificate Authority Service 实例中的哪个 CA 池为工作负载身份池中的身份生成 X.509 证书。配置文件还指定了证书的生命周期、轮替窗口百分比和密钥算法。

证明政策强制执行成功后，CA 池会向托管式工作负载身份颁发 X.509 证书。

工作负载身份池的内嵌信任配置

默认情况下，同一信任域中的工作负载可以使用托管式工作负载身份相互进行身份验证。如果您希望位于不同信任域中的工作负载相互进行身份验证，则需要在工作负载身份池中明确声明信任关系。为此，您可以创建一个内嵌信任配置，用于识别和接受来自其他信任域的证书。这些证书用于构建信任链并验证来自其他网域的工作负载的身份。

内嵌信任配置包含一组信任锚，托管式工作负载身份会使用这些信任锚来验证对等证书。Certificate Manager 信任配置封装了 SPIFFE 受信任证书存储区，该存储区与工作负载身份池的内嵌信任配置保持同步。

由于工作负载身份池已绑定到 CA 池，因此工作负载身份池会自动信任该 CA 池的根证书。您无需将池的 CA 根添加到内嵌信任配置中，因为该信任已内置。

在下图中，负载均衡器和后端属于同一信任网域，共享同一根证书。根证书用于构建信任链并验证信任域内工作负载的身份。

托管式工作负载身份资源层次结构（点击可放大）。

后端服务 (Compute Engine API)

如需为负载均衡器分配代管式身份，您需要配置负载均衡器的后端服务，使其 tlsSettings 属性指向新的 identity 属性 (backendService.tlsSettings.identity)。

请注意，在负载均衡器的后端服务上使用 identity 字段时，存在以下限制：

• 如果您设置了 identity 属性，则无法在 tlsSettings 属性中手动设置以下字段：

  • tlsSettings.sni
  • tlsSettings.subjectAltNames
  • tlsSettings.authenticationConfig

• identity 字段只能在创建后端服务期间分配。

• identity 字段不可更改。将一个安全政策分配给负载均衡器的后端服务后，该安全政策便无法更新或删除。

自动创建的资源

在负载均衡器的后端服务上设置 identity 属性 (backendService.tlsSettings.identity) 后，托管式工作负载身份会自动在 Certificate Manager API 和网络安全 API 中创建以下资源。

自动创建的资源与后端服务在同一项目中创建，并使用该项目中的标准配额。

Certificate Manager 信任配置 (Certificate Manager API)

Certificate Manager 信任配置是自动创建的，无法直接修改或删除。

Certificate Manager 信任配置包含一个名为 spiffeTrustStores 的字段。spiffeTrustStores 字段包含与工作负载身份池的信任域关联的信任包，以及工作负载身份池的内嵌信任配置中的 additionalTrustBundles 字段指定的任何其他信任包。如需了解详情，请参阅验证 Certificate Manager 信任配置是否包含 spiffeTrustStores 字段。

如需详细了解 Certificate Manager 信任配置中的 spiffeTrustStores 字段如何允许验证 SPIFFE 证书，请参阅服务器证书验证步骤。

Certificate Manager 托管式身份证书 (Certificate Manager API)

Certificate Manager 托管式身份证书由托管式工作负载身份自动创建。Certificate Manager 托管式身份证书是只读的，无法使用 Certificate Manager API 直接修改或删除。Certificate Manager 托管式身份证书基于内嵌证书颁发配置，该配置在工作负载身份池中定义。

Certificate Manager 代管式身份证书具有 managedIdentity 属性，可将其标识为代管式身份证书。Certificate Manager 托管式身份证书资源以 PEM 编码格式存储 X.509-SVID。此 X.509-SVID 包含在 SAN 字段中编码为 URI 的 SPIFFE ID。此 SPIFFE ID 对应于工作负载身份池中的托管式身份。

Certificate Manager 托管式身份证书的范围是 CLIENT_AUTH，这表示此证书在后端 mTLS 中用作客户端证书。

后端身份验证配置 (网络安全 API)

后端身份验证配置由托管式工作负载身份自动创建。后端身份验证配置是只读的，无法使用网络安全 API 直接修改或删除。

Certificate Manager 信任配置已附加到后端身份验证配置。

Certificate Manager 托管式身份证书也会附加到后端身份验证配置，并在负载均衡器与目标工作负载之间的后端 mTLS 请求中用作 X.509-SVID。

多区域部署的 CA 层次结构要求

当不同 Google Cloud 区域中的后端虚拟机使用托管式工作负载身份获取其服务器证书时，每个区域中的虚拟机都必须从位于同一区域的 CA 池请求证书。

如果您的负载均衡器是全球负载均衡器（全球外部应用负载均衡器或跨区域内部应用负载均衡器），且后端位于多个区域，则您必须设置一个 CA 层次结构，其中包含单个共享根 CA（位于任何区域）和每个区域中的从属 CA 池（后端所在区域）。请勿在每个区域中创建单独的自签名根 CA；工作负载身份池中的所有区域级 CA 池都必须链接到同一根 CA，以便所有区域中的负载均衡器和后端共享一个信任根。

将托管式工作负载身份分配给全球后端服务时，托管式工作负载身份会自动创建全球 Certificate Manager 信任配置，并仅使用工作负载身份池的内嵌证书颁发配置中单个任意区域的 CA 池颁发全球托管式身份客户端证书。如果您的后端跨多个区域，并且您在每个区域中配置单独的自签名根 CA，而不是由单个共享根 CA 签名的从属 CA，则该单个区域之外的后端将无法通过 mTLS 身份验证。

服务器证书验证步骤

在后端 mTLS 期间验证服务器证书时，负载均衡器会执行以下操作：

1. 验证服务器是否拥有证书的私钥。

   服务器使用其私钥为某条信息签名，并将其作为 CertificateVerify 消息的一部分发送给负载均衡器，从而证明其拥有与其向负载均衡器提供的证书关联的私钥。然后，负载均衡器会使用服务器证书中的公钥验证此签名。如果签名验证失败，则表示后端服务器不具备与证书对应的私钥。在此类情况下，负载均衡器会终止 TLS 握手，而不会记录任何错误。

2. 验证信任链。

   Certificate Manager 信任配置中的 spiffeTrustStores 字段允许验证 SPIFFE 证书。 使用托管式工作负载身份时，系统会自动启用 Certificate Manager 信任配置中的 spiffeTrustStores 字段。启用 spiffeTrustStores 字段后，trustStores 字段仍为空。

   spiffeTrustStores 字段是一个映射数据结构，其中键值对如下所示：

   • 该键既可以是与工作负载身份池相关的信任域（格式以 .workload.id.goog 结尾），也可以是其他信任域。
   • value 是 TrustStore 对象。此对象包含一组可信根证书（称为信任软件包），用于验证来自该特定信任域的 SPIFFE 证书。

   从本质上讲，此映射允许使用来自多个不同安全网域的受信任证书存储区来配置负载均衡器。当后端提供其 SPIFFE 证书时，负载均衡器会提取 SPIFFE ID，识别信任域，并使用 spiffeTrustStores 映射查找正确的受信任证书存储区，以验证信任链和证书。

   验证检查包括：

   • 后端的服务器证书、中间证书（如果提供）和已配置的根证书是否符合证书要求。
   • 对于信任链中的所有证书，父证书中的主体字段与子证书中的颁发机构字段匹配。此验证有助于确保父证书的身份（主体）与子证书中列为颁发者的身份相同。
   • 对于信任链中的所有证书，父证书的主体密钥标识符 (SKID) 与子证书中的授权机构密钥标识符 (AKID) 匹配。此匹配结果确认了子证书是由正确的根授权机构颁发的，并且可以信任，因为 AKID 中引用了根的公钥，以验证证书的有效性。
   注意：自签名客户端证书无法形成有效的信任链，因此始终会被拒绝。

3. 与后端建立连接。

   如果证书验证成功，负载均衡器会继续与后端建立连接。

   但是，如果证书验证失败，负载均衡器会终止与后端的连接，向客户端发送 HTTP 502 状态代码，并将终止原因记录到 Cloud Logging。如果发生证书验证错误，后续传入的请求会触发负载均衡器重新发起后端连接。

   如果后端服务器拒绝连接，后端连接也可能会失败。对于后端 mTLS，可能会发生这种情况，因为它会发现客户端证书无效。与后端的连接失败时，负载均衡器会使用 HTTP 502 状态代码响应代理请求，并将常规错误原因记录到 Cloud Logging。

错误处理和日志记录

Application Load Balancer 提供详细的日志记录功能，可让您监控服务器证书验证、发现潜在问题并排查连接问题。本部分概述了在 mTLS 验证期间可能发生的不同类型的错误以及如何记录这些错误。

如果服务器证书验证失败，则系统会终止连接并将错误记录到 Cloud Logging。下表介绍了这些错误。

服务器证书状态	记录的错误
服务器证书链过长（服务器证书包含超过 10 个中间证书）。	server_cert_chain_exceeded_limit
服务器证书或中间证书的 RSA 密钥大小无效。 不执行验证。 RSA 密钥可为 2048 位到 4096 位。	server_cert_invalid_rsa_key_size
服务器证书或中间证书使用的是不受支持的椭圆曲线。 不执行验证。 有效曲线为 P-256 和 P-384。	server_cert_unsupported_elliptic_curve_key
服务器证书或中间证书使用非 RSA、非 ECDSA 算法。 不执行验证。	server_cert_unsupported_key_algorithm
用于验证的 PKI 具有 10 个以上的中间证书，它们共享相同的主体和主体公钥信息。 不执行验证。	server_cert_pki_too_large
为验证提供的中间证书有超过 10 个名称限制。	server_cert_chain_max_name_constraints_exceeded
服务器证书具有 Extended Key Usage (EKU) 扩展字段，但该字段不包含 serverAuth。	server_cert_chain_invalid_eku
尝试验证证书链时超出了时间限制。	server_cert_validation_timed_out
在尝试验证证书链时达到深度或迭代限制。 证书链的深度上限为 10，包括根证书和服务器证书。迭代次数上限为 100（为验证服务器证书链所检查的证书的数量）。	server_cert_validation_search_limit_exceeded
您在未设置 TrustConfig 资源的情况下配置了 mTLS。	server_cert_validation_not_performed
服务器在握手期间未提供请求的证书。	server_cert_not_provided
服务器证书未通过 TrustConfig 资源验证。	ssl_certificate_verification_failed
服务无法执行证书链验证。	server_cert_validation_unavailable
验证证书链时发生内部错误。	server_cert_validation_internal_error
找不到 TrustConfig 的匹配项。	server_cert_trust_config_not_found
服务器证书载荷（包括所有中间证书）过大（超过 16 KB）。	server_cert_exceeded_size_limit

限制

• 传统应用负载均衡器不支持后端 mTLS。

• 全球互联网 NEG 后端不支持后端 mTLS。

• 如果您为后端服务 (backendService.tlsSettings.identity) 分配了托管式身份，则无法在后端服务的 tlsSettings 属性中手动设置以下字段：

  • backendService.tlsSettings.sni
  • backendService.tlsSettings.subjectAltNames
  • backendService.tlsSettings.authenticationConfig

• 托管式身份只能在创建后端服务时分配。

• 托管式身份不可变。为负载均衡器的后端服务分配托管式身份后，该身份便无法更新或删除。

后续步骤

• 使用托管式工作负载身份设置后端 mTLS