Google Cloud在2026年9月18日宣布，面向应用负载均衡器后端mTLS的托管工作负载身份正式商用。负载均衡器可以使用基于SPIFFE ID的身份向后端证明自己，并由Certificate Authority Service自动签发和轮换X.509证书。
这项能力把客户端证书、信任配置和后端认证配置的部分维护工作交给平台，适合需要在负载均衡层与内部服务之间建立双向认证的架构。不过，身份字段的创建时机和不可变规则意味着现有后端服务不能直接照搬配置。
正式商用覆盖四类应用负载均衡器
官方列出的支持范围包括全球外部、区域外部、跨区域内部和区域内部Application Load Balancer。负载均衡器的backend service充当源工作负载，后端实例或服务充当目标工作负载，双方通过mTLS验证证书与工作负载身份。
这次更新面向Application Load Balancer，不代表所有Google Cloud负载均衡产品都自动获得同一能力。经典应用负载均衡器不支持后端mTLS，全球Internet NEG后端也不在支持范围内。
证书签发和信任配置由平台联动完成
管理员仍需配置CA池、TRUST_DOMAIN模式的工作负载身份池、命名空间、托管身份、证明策略以及证书签发和信任规则。把托管身份分配给backend service后，平台会自动创建Certificate Manager托管身份证书、SPIFFE信任配置和后端认证配置。
证书中的URI SAN编码SPIFFE ID，负载均衡器和后端据此确认对方属于受信任域。自动化减少的是证书和关联资源维护，不会替代信任域、证明策略与CA层级设计。
身份只能在创建后端服务时写入
官方限制指出，backendService.tlsSettings.identity只能在创建backend service时分配，写入后不能更新或删除。设置托管身份后，也不能同时手动设置SNI、Subject Alternative Names或authenticationConfig。
已有backend service不能假设可以原地切换身份字段。生产迁移应先新建并验证一套后端服务，确认健康检查、流量切换与回滚路径，再逐步替换旧资源。
后端证书仍必须符合严格校验要求
后端提供的服务器证书需要包含serverAuth用途、有效的证书链且没有过期；算法只支持RSA或ECDSA，哈希需要SHA-256或更强。负载均衡器的客户端证书由Certificate Manager自动管理并包含clientAuth用途。
证书链验证失败时，负载均衡器会终止连接，对客户端返回HTTP 502，并把失败原因写入Cloud Logging。证书托管不等于握手永远成功，后端证书用途、链路与算法仍需单独验收。
迁移验收应同时观察身份和业务流量
上线前需要核对CA配额、工作负载身份池、证明策略、后端证书链和区域支持，并在测试流量下观察TLS握手、健康检查、502比例及Cloud Logging中的证书错误代码。跨信任域通信还要明确配置额外信任关系。
最终验收标准应是自动轮换后连接持续成功，未授权工作负载被拒绝，而且业务延迟和错误率没有异常。只看到托管证书资源已创建，不能证明后端mTLS已经安全运行。
