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

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

您也可以在不使用托管式工作负载身份的情况下实现后端 mTLS。如需详细了解不使用托管式工作负载身份的后端 mTLS，请参阅后端经过身份验证的 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。
使用托管式工作负载身份的后端 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 等哈希算法。

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

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

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

使用托管式工作负载身份的后端 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 架构（点击可放大）。

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

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

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

明确创建的资源

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

证书授权机构池

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

您可以使用 CA Service 池来设置此层次结构。

通过使用内嵌证书颁发配置更新工作负载身份池，将工作负载身份池绑定到 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

证明政策

证明政策包含一些规则，供 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 根证书添加到内嵌信任配置中，因为该信任已内置。

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

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

后端服务 (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 和 Network Security 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）

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

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

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

服务器证书验证步骤

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

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

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

  2. 验证信任链。

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

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

    • 该键可以是与工作负载身份池相关的信任网域（格式以 .workload.id.goog 结尾），也可以是其他信任网域。
    • 值是一个 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 与托管式工作负载身份只能针对全球外部应用负载平衡器进行配置。传统应用负载平衡器不支持后端 mTLS。

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

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

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

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

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

后续步骤