4. Envoy 安全基础：TLS/SSL 配置、证书管理、mTLS 双向认证原理

在云原生服务网格中，Envoy 代理位于所有东西向与南北向流量的关键路径上。为流量提供传输层加密与身份认证是保障网格安全的第一道防线。本章深入剖析 Envoy 的 TLS/SSL 配置模型、证书生命周期管理以及双向认证（mTLS）的实现原理，为后续的基线核验打下坚实基础。

4.1 TLS/SSL 配置核心模型

Envoy 通过 DownstreamTlsContext（监听端）与 UpstreamTlsContext（连接上游端）两个独立配置块来管理 TLS。这种分离设计允许代理在入口和出口方向使用不同的证书策略与加密套件。

配置上下文	作用方向	典型场景	关键字段
DownstreamTlsContext	Listener → Client	入口网关、Sidecar 入站	common_tls_context, require_client_certificate
UpstreamTlsContext	Cluster → Upstream	Sidecar 出站、Egress 网关	common_tls_context, sni, allow_renegotiation

以下是一个典型的 DownstreamTlsContext 配置片段，展示如何为 HTTPS 监听器启用 TLS 1.3 并指定证书链：

static_resources:
  listeners:
  - name: ingress_https
    address:
      socket_address: { address: 0.0.0.0, port_value: 443 }
    filter_chains:
    - filter_chain_match:
        transport_protocol: tls
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsConfig
          common_tls_context:
            tls_params:
              tls_minimum_protocol_version: TLSv1_2
              tls_maximum_protocol_version: TLSv1_3
              cipher_suites: [
                "ECDHE-ECDSA-AES128-GCM-SHA256",
                "ECDHE-RSA-AES128-GCM-SHA256"
              ]
            tls_certificates:
            - certificate_chain: { filename: "/etc/envoy/certs/server.crt" }
              private_key: { filename: "/etc/envoy/certs/server.key" }
          require_client_certificate: false

4.2 证书管理与轮换策略

Envoy 支持静态文件加载与动态 SDS（Secret Discovery Service）两种证书获取方式。在生产环境中，SDS 是实现零停机证书轮换的推荐方案。

• 静态文件加载： 通过 filename 或 inline_bytes 直接指定证书与密钥。变更需重启 Envoy 或通过 LDS/RDS 热更新。
• SDS 动态获取： 通过 sds_config 指向 SDS 集群，Envoy 实时监听证书变更，无需重启即可完成轮换。

以下 SDS 配置示例展示了如何通过 SDS 动态获取服务器证书：

common_tls_context:
  tls_certificate_sds_secret_configs:
  - name: server_cert
    sds_config:
      path: "/etc/envoy/sds/sds_config.yaml"
      resource_api_version: V3

4.3 mTLS 双向认证原理

mTLS（双向 TLS）在标准 TLS 握手基础上，要求客户端也必须出示证书供服务端验证。Envoy 通过 require_client_certificate: true 与 validation_context 实现这一机制。

完整的 mTLS 握手流程包含以下步骤：

1. 客户端发起 ClientHello，协商 TLS 版本与密码套件。
2. 服务端返回 ServerHello 及其证书链（Server Certificate）。
3. 服务端发送 CertificateRequest，要求客户端提供证书。
4. 客户端验证服务端证书后，发送自己的 Client Certificate 与 CertificateVerify。
5. 双方完成密钥交换，建立加密隧道。

4.4 Envoy mTLS 配置实战

在 Envoy 中启用 mTLS 需要同时配置服务端验证客户端证书，以及客户端提供自身证书。以下是一个完整的 DownstreamTlsContext 启用 mTLS 的示例：

transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsConfig
    common_tls_context:
      tls_params:
        tls_minimum_protocol_version: TLSv1_2
      tls_certificates:
      - certificate_chain: { filename: "/etc/envoy/certs/server.crt" }
        private_key: { filename: "/etc/envoy/certs/server.key" }
      validation_context:
        trusted_ca: { filename: "/etc/envoy/certs/ca.crt" }
        match_typed_subject_alt_names:
        - san_type: DNS
          matcher:
            exact: "client.example.com"
    require_client_certificate: true

4.5 证书验证与 SAN 匹配

Envoy 支持对客户端证书进行多维度验证，包括 CA 信任链校验、有效期检查以及 SAN（Subject Alternative Name）匹配。SAN 匹配是防止中间人攻击的关键手段。

验证维度	配置字段	说明
CA 信任链	validation_context.trusted_ca	指定根 CA 或中间 CA 证书，用于验证证书签发者
证书有效期	自动校验	Envoy 自动检查证书的 notBefore 与 notAfter 字段
SAN 精确匹配	match_typed_subject_alt_names	支持 DNS、IP、URI 等 SAN 类型的精确或通配符匹配
CRL 吊销检查	validation_context.crl	可选配置，指定证书吊销列表文件

4.6 基线核验要点

在 CIS 基准核验中，TLS/mTLS 配置是重点检查项。以下是与本章内容直接相关的核验要点：

• TLS 版本控制： 确认 tls_minimum_protocol_version 不低于 TLSv1_2，禁止使用 SSLv3 或 TLSv1.0。
• 密码套件限制： 仅允许 AEAD 类密码套件（如 AES-GCM、ChaCha20-Poly1305），禁用 RC4、3DES、CBC 模式。
• 证书轮换机制： 验证是否使用 SDS 动态获取证书，确保证书到期前 30 天自动轮换。
• mTLS 强制启用： 在网格内部通信中，确认 require_client_certificate 设置为 true，且 validation_context 配置了正确的 CA。
• SAN 匹配： 检查 match_typed_subject_alt_names 配置，确保客户端证书的 SAN 与预期身份一致。