Kubernetes 服务网格双向 TLS 落地：服务间加密验证与故障回滚

在已部署服务网格的 Kubernetes 集群中，服务间通信通常经过代理或网格数据平面。若工作负载之间仍接受明文连接，网络路径上的流量可能缺少传输加密和对端身份校验。启用双向 TLS（mTLS）可以让通信双方在连接中验证彼此的工作负载身份并加密传输，但它本身不等于访问授权：认证通过并不代表调用方应当获得某项服务或操作的权限。

具体策略资源、字段、默认行为和生效范围取决于服务网格实现及其版本。以下步骤以已部署网格、由网格数据平面处理服务间流量为前提；执行前应核对当前网格版本的官方文档，并在授权的测试或预生产环境先验证。

准备：确认范围与兼容性

先明确要保护的服务、通信方向和变更边界。按工作负载记录命名空间、Deployment 或其他控制器、ServiceAccount、入口与调用方，以及调用关系和关键业务路径。还要标出不经网格代理的流量、外部依赖、遗留客户端及探针等特殊连接；它们可能不受本次网格策略覆盖，或会因严格策略而中断。

保存当前配置和变更前基线：

kubectl get namespaces
kubectl get deployments,services -n <namespace> -o wide
kubectl get pods -n <namespace> -o wide
kubectl get networkpolicies -A

另行导出相关网格策略、工作负载清单及部署配置，并记录关键服务的请求成功率、延迟、错误率和连接失败情况。确认回滚时能恢复原策略，且有可用的操作权限和变更窗口。

兼容性检查应覆盖：

• 网格控制面与数据平面版本、策略 API 支持情况，以及目标工作负载是否已纳入网格。
• 调用方和接收方是否都经过预期的数据平面路径，是否存在旁路、裸 Pod IP 调用或网格外客户端。
• 证书签发、信任关系、轮换与代理健康状况。若证书无法正常提供或验证，严格 mTLS 可能导致连接失败。
• 应用是否依赖非预期的协议、端口或连接行为；探针、批处理任务和运维工具是否也会访问目标服务。
• 现有授权策略是否会与新身份或策略范围冲突，以及如何从观测结果确认调用方身份。

mTLS 的策略范围可以是整个网格、命名空间或单个工作负载，具体能力和配置方式依平台而异。以 Istio 兼容实现为例，Google Cloud Service Mesh 文档说明，可通过 PeerAuthentication 限制服务只接受 mTLS；其 Kubernetes 工作负载的自动 mTLS 行为并不意味着接收方已经拒绝明文流量。部署前应核对对应平台的支持字段和版本说明：Cloud Service Mesh 传输安全配置。

实施：分阶段收紧策略

不要在未确认通信路径和恢复方式前直接对全网格启用严格模式。建议从低风险、调用关系清晰的命名空间或单个工作负载开始，观察稳定后再扩大范围。

先核实身份与策略作用域

确认服务网格中调用方和接收方实际呈现的工作负载身份，并检查当前策略是否覆盖预期对象。避免只按 IP 地址推断服务身份，也不要假设所有 Pod 都已被网格纳管。

策略配置应分别考虑两件事：

1. 传输认证与加密：接收方要求使用 mTLS，验证连接对端是否具有受信任的网格身份。
2. 访问授权：依据网格身份、命名空间、服务或请求属性，明确哪些调用方可访问哪些资源或操作。

只启用 mTLS 而保持授权过于宽松，仍可能允许不应访问的工作负载调用服务。反过来，授权规则也不能替代传输加密。应分别审阅并测试这两类策略。

试点启用，再扩大范围

先对一个非关键服务或隔离的试点命名空间收紧接收策略。配置前后都保存策略清单，并使用当前网格版本的官方示例核对字段。不同平台的资源名称、默认模式和策略优先级可能不同，不要将一个实现的 YAML 直接套用到另一个实现。

试点通过后，按命名空间或服务逐批推进。每批变更后观察连接错误和业务指标，再继续下一批。部署操作可以通过适用于当前网格的配置工具完成，例如：

kubectl apply -f <试点策略文件>
kubectl get <网格策略资源> -n <namespace> -o yaml

尖括号中的资源类型和文件名需替换为实际值。变更前确认策略选择器与命名空间范围准确，避免标签不匹配导致策略未生效，或范围过大造成意外影响。

验证：正向、反向与业务连接测试

验证不能只看策略对象已创建。至少要确认数据平面已接收配置、预期连接成功、非预期连接被拒绝，并且关键业务链路仍正常。

测试端应处于授权的测试范围内，避免使用生产中未批准的探测方式。可以通过应用自身健康检查或受控客户端发起请求；同时核对代理和控制面的策略同步状态。不要仅凭客户端收到超时就认定 mTLS 生效，因为网络策略、服务发现或应用故障也可能产生类似现象。

监控观察点包括成功率、延迟、连接重试、握手或证书验证错误、代理健康状态、授权拒绝计数，以及受影响服务的日志和告警。比较变更前后的基线，并按命名空间、工作负载和调用方向定位异常。若出现证书或信任错误，应先确认身份与证书状态；若出现授权拒绝，应核对策略是否符合预期，而不是通过扩大授权范围掩盖问题。

故障处置与回滚

当业务连接中断或错误率明显升高时，先停止扩大变更范围，记录时间、受影响工作负载、策略版本及相关代理日志。按已评估的恢复路径处理：

1. 确认故障是否与本次策略变更相关，并检查控制面、数据平面、证书状态及策略作用域。
2. 若影响仍局限于试点，先恢复该试点变更前保存的策略；不要直接删除范围更大的共享策略。
3. 若当前策略已阻断关键通信，按网格官方文档将受影响范围恢复到变更前的接受模式，或回滚到保存的策略版本。具体回滚字段和命令取决于网格实现与版本。
4. 等待配置传播后，从受影响调用方重新执行正向业务测试，并检查错误率、延迟及代理日志是否恢复。
5. 记录回滚时间、变更内容、影响范围和恢复证据；修正兼容性或授权规则后，再以更小范围重新试点。

回滚到允许明文的状态会降低传输保护，应作为有时限的恢复措施，限制影响范围并安排重新启用和复测。若无法判断应恢复哪份策略，不要对共享资源进行盲目覆盖；先从已保存的变更前配置和网格控制面状态确认目标版本。

复盘：确认保护边界

变更完成后，核对哪些工作负载要求 mTLS、哪些流量仍在网格之外，以及哪些授权规则限制了调用者。保留策略版本、试点与回滚记录、正反向测试结果和监控对比，便于后续审计与变更复核。

最终结论应区分“传输已加密并完成对端认证”与“调用已获授权”。mTLS 保护的是符合网格策略覆盖范围内的连接；它不会自动证明请求者有权执行某项业务操作，也不保证未经过网格的数据路径受到相同保护。