微服务中的服务网格Sidecar代理与外部服务集成时的TLS终止/启动（TLS Termination/Origination）机制

我们来深入探讨在微服务架构中，当服务需要与外部服务（即位于服务网格之外、不受Sidecar代理直接管理的服务，如第三方API、遗留系统或云服务）进行安全通信时，服务网格Sidecar代理如何通过TLS终止和TLS启动机制来保障、管理和简化通信的安全性。

一、核心概念与背景

• TLS（传输层安全协议）：是保障网络通信（特别是HTTP）加密、身份认证和数据完整性的标准协议。HTTPS就是HTTP over TLS。
• TLS终止：在代理（如Sidecar、API网关、负载均衡器）处，对入站（Ingress）的TLS加密流量进行解密，将其转换为代理内部的明文或不同安全等级的流量，以便代理进行处理（如路由、检查、修改）。
• TLS启动：在代理处，对出站（Egress）的流量进行加密，发起一个全新的TLS连接到目标服务。这是“启动”一个新的TLS会话。
• 外部服务：特指不托管在服务网格内、其网络流量不受网格数据平面Sidecar代理透明拦截和管理的服务。
• 核心挑战：网格内部的服务间通信可以通过Sidecar自动实现mTLS，但外部服务通常不受此控制。如何让内部服务安全、便捷、可管理地访问外部服务，是此机制要解决的关键问题。

二、机制详解：为什么需要这两种机制？

假设一个场景：网格内的服务A 需要调用 网格外的外部API（https://api.external.com）。

没有Sidecar代理TLS管理的情况：

1. 服务A必须自己处理所有TLS逻辑：加载信任的CA证书、验证外部服务的证书、协商加密套件、维护TLS连接。
2. 运维困难：证书轮换、TLS版本/密码套件升级、安全策略执行（如禁止访问特定不安全的域名）都需要在每个应用内修改和部署，难以统一管控。
3. 可观测性差：TLS层以上的流量对基础设施不可见，难以监控、记录和进行高级流量治理。

引入Sidecar代理的TLS终止/启动机制：
Sidecar代理（如Istio的Egress Gateway或Pod内的Sidecar）可以代表应用程序，统一处理与外部服务的TLS通信，将安全策略与业务逻辑解耦。

三、TLS终止/启动的具体工作流程

这个过程主要发生在出站流量（Egress）场景，可以分为两个核心操作，有时是分离的，有时是连续的。

第一步：网格内部到Sidecar的通信处理

A. 从应用容器到Sidecar（可选TLS终止）

1. 流量拦截：服务A向api.external.com发出的HTTP请求，首先被本Pod内的Sidecar代理（通过iptables/BPF规则）透明拦截。
2. 内部TLS终止：如果网格内部配置了严格的双向TLS（strict mTLS），那么服务A与自己的Sidecar之间的连接已经是mTLS加密的。此时，Sidecar接收到这个请求时，首先会执行一次TLS终止，即解密来自服务A的mTLS流量，得到明文（或应用层协议数据）。
3. 策略执行：Sidecar在获得明文请求后，可以对其应用各种治理策略，如：
   • 出站流量策略检查：检查目标主机api.external.com是否在允许访问的白名单中。
   • 请求级操作：添加、删除或修改HTTP头，进行日志记录，采集指标。

第二步：Sidecar到外部服务的通信处理

B. 从Sidecar到外部服务（TLS启动）
这是本机制的核心环节。Sidecar作为客户端，代表服务A去连接外部服务。

1. 发起新连接：Sidecar根据请求的目标地址（经过可能的路由改写后），与api.external.com建立一个全新的TCP连接。
2. TLS握手：Sidecar在此连接上启动（Originate） 一个TLS握手。这个握手过程完全由Sidecar控制，与业务服务A无关。
3. 证书与验证：
   • Sidecar需要配置信任的CA证书，用于验证外部服务提供的服务器证书，确保连接的是真实的api.external.com，而非中间人攻击。
   • （可选）如果外部服务要求客户端证书认证，Sidecar也需要配置客户端证书和私钥，在握手时提供给外部服务。这实现了出站方向的mTLS。
4. 加密传输：TLS握手成功后，Sidecar将第二步中处理过的明文请求，通过这个新建的、加密的TLS连接发送给外部服务api.external.com。
5. 接收与回传响应：外部服务的响应加密返回给Sidecar。Sidecar接收后，先终止这个来自外部的TLS连接（即解密），得到明文响应。之后，如果需要，再通过内部的mTLS加密连接，将响应传回给服务A。

四、核心价值与优势

1. 统一安全管理：
   • 证书管理：应用的开发者无需关心外部服务的证书。TLS版本、密码套件、证书轮换等都由平台团队在Sidecar或Egress Gateway层面统一配置和管理。
   • 策略执行：可以集中定义和执行安全策略，例如“禁止访问证书已过期的外部服务”或“必须使用TLS 1.3”。
2. 增强可观测性：
   • 由于Sidecar代理是TLS握手的端点，它可以获取TLS层的详细指标，如握手成功率、握手延迟、使用的TLS版本和密码套件。这些指标对运维和安全审计至关重要。
3. 简化应用代码：
   • 应用可以像调用HTTP服务一样简单（甚至可以调用http://），复杂的TLS逻辑由Sidecar处理，降低了应用开发的复杂度和出错概率。
4. 灵活的流量治理：
   • 在明文阶段，可以方便地进行流量路由、重试、超时设置、故障注入、请求/响应头修改等。

五、常见架构模式

1. 直接Sidecar出口模式：每个Pod的Sidecar直接处理对外部服务的TLS启动。配置简单，但策略分散在每个Pod。
2. 专用出口网关（Egress Gateway）模式：
   • 网格内的服务首先将对外部服务的请求发送到一个中心化的Egress Gateway Pod。
   • 由这个Egress Gateway统一执行TLS启动，连接到外部服务。
   • 优势：提供了单一控制点，便于实施统一的安全、监控和计费策略。所有对外流量都经过一个已知的出口IP，方便企业防火墙规则配置。

六、在Istio中的配置示例（概念性）

在Istio中，主要通过以下资源配置：

• ServiceEntry：定义网格可识别的外部服务api.external.com，并声明其端口和协议（如HTTPS）。
• DestinationRule：为访问api.external.com配置流量策略。在其中的trafficPolicy.tls字段，可以设置TLS启动的模式。

  apiVersion: networking.istio.io/v1beta1
  kind: DestinationRule
  metadata:
    name: external-api-dr
  spec:
    host: api.external.com
    trafficPolicy:
      tls:
        mode: SIMPLE # TLS启动模式。SIMPLE表示发起TLS连接到外部服务，并验证其服务器证书。
        caCertificates: /etc/certs/external-ca-root.pem # （可选）指定验证服务器证书的CA
        clientCertificate: /etc/certs/client-cert.pem # （可选）客户端证书，用于mTLS
        privateKey: /etc/certs/client-key.pem # （可选）客户端私钥
  

• Gateway 与 VirtualService（Egress Gateway模式）：定义出口网关，并将到api.external.com的流量路由到网关，由网关执行TLS启动。

总结

微服务中服务网格Sidecar代理的TLS终止/启动机制，本质上是将复杂的TLS安全通信能力从业务应用中下沉到基础设施层。TLS终止用于接收并处理加密流量，TLS启动则用于主动发起安全的对外连接。二者协同工作，为微服务与外部系统的集成提供了统一、安全、可观测、可治理的通道，是实现零信任安全模型中“对所有流量加密”原则的关键技术，同时极大地简化了应用程序的开发与运维负担。