📚 课程目录第3章 Istio mTLS工作模式

3. Istio mTLS 工作模式：PERMISSIVE、STRICT、DISABLE 详解与适用场景

在 Istio 服务网格中，mTLS（双向 TLS）是保障服务间通信机密性与身份可信的核心机制。Istio 通过 PeerAuthentication 策略资源控制 mTLS 的工作模式，支持三种模式：PERMISSIVE、STRICT 和 DISABLE。理解这三种模式的差异、流量行为及适用场景，是规划 mTLS 升级路径与证书管理策略的基础。

3.1 三种模式核心对比

模式	入站（Server）行为	出站（Client）行为	安全等级	兼容性
DISABLE	仅接受明文 TCP（非 mTLS）	仅发送明文 TCP	无加密与身份验证	完全兼容非网格客户端
PERMISSIVE	同时接受明文与 mTLS 连接	优先发送 mTLS，若失败回退明文	中等（允许降级）	兼容非网格与网格客户端
STRICT	仅接受 mTLS 连接	仅发送 mTLS 连接	最高（强制加密与身份）	仅兼容网格内客户端

关键理解：PeerAuthentication 策略作用于目标服务端的入站监听器。客户端的行为由目标端策略间接决定——当目标端为 STRICT 时，客户端必须使用 mTLS；当目标端为 PERMISSIVE 时，客户端优先使用 mTLS，但允许降级。

3.2 模式详解与流量行为

3.2.1 DISABLE 模式

当命名空间或工作负载的 PeerAuthentication 设置为 DISABLE 时，Envoy 代理将完全关闭 mTLS 功能。服务端代理仅监听明文 TCP 连接，客户端代理也仅发送明文请求。此模式下，网格不提供任何传输层加密或身份验证。

流量特征：所有服务间通信均为明文 HTTP/TCP。
证书状态：Sidecar 仍会从 Citadel 获取证书，但不会用于入站/出站连接。
典型场景：调试阶段、性能压测（排除加密开销）、与不支持 TLS 的遗留系统对接。

安全风险：DISABLE 模式完全放弃传输安全，生产环境应避免使用。即使在内网，明文通信也面临中间人攻击与数据泄露风险。

3.2.2 PERMISSIVE 模式

PERMISSIVE 是 Istio 的默认模式，也是从非网格环境向 STRICT 模式迁移的桥梁模式。服务端代理同时监听两个端口：一个用于明文连接，一个用于 mTLS 连接。客户端代理优先尝试 mTLS 握手，若失败则回退到明文。

流量特征：网格内客户端使用 mTLS，非网格客户端使用明文，两者共存。
证书状态：Sidecar 正常使用证书进行 mTLS 握手，同时保留明文监听能力。
典型场景：网格逐步推广阶段、混合部署（部分服务未注入 Sidecar）、mTLS 升级过渡期。

  升级策略：推荐先全局设置为 PERMISSIVE，观察一段时间确保所有服务通信正常，再逐步切换至 STRICT。PERMISSIVE 模式允许你“先跑通，再加固”。

3.2.3 STRICT 模式

STRICT 模式强制所有服务间通信必须使用 mTLS。服务端代理仅接受带有有效客户端证书的 TLS 连接，拒绝所有明文请求。客户端代理仅发送 mTLS 连接，不会尝试明文回退。

流量特征：100% 加密通信，每个请求都携带 SPIFFE 身份证书。
证书状态：证书成为通信的必需组件，证书过期或吊销将直接导致通信失败。
典型场景：生产环境安全基线、合规要求（如 PCI-DSS、SOC2）、多租户隔离场景。

3.3 模式切换流程与适用场景决策

下图展示了从 DISABLE 到 STRICT 的典型升级路径，以及各阶段对应的适用场景：

3.4 策略配置示例

以下 YAML 展示了如何在命名空间级别和工作负载级别配置 PeerAuthentication：

# 全局默认：PERMISSIVE（Istio 默认行为）
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: PERMISSIVE
---
# 命名空间级别：强制 STRICT
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: strict-ns
  namespace: production
spec:
  mtls:
    mode: STRICT
---
# 工作负载级别：对特定服务禁用 mTLS
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: legacy-svc-disable
  namespace: production
spec:
  selector:
    matchLabels:
      app: legacy-payment
  mtls:
    mode: DISABLE

策略优先级：工作负载级别 > 命名空间级别 > 网格级别（istio-system 中的默认策略）。细粒度策略可以覆盖粗粒度设置，实现精准控制。

3.5 模式切换的流量影响与避坑指南

在生产环境中切换 mTLS 模式时，需关注以下关键影响：

切换动作	潜在影响	建议措施
PERMISSIVE → STRICT	未注入 Sidecar 的客户端连接被拒绝	先确认所有调用方均已注入 Sidecar 或已迁移
STRICT → PERMISSIVE	安全等级降级，明文流量可能进入	仅用于应急回退，事后需恢复 STRICT
DISABLE → PERMISSIVE	客户端证书验证逻辑突然启用，可能引发延迟抖动	先在低流量服务上灰度验证
证书过期时 STRICT	服务间通信完全中断	配置证书自动轮换，监控证书过期时间

重要提醒：在 STRICT 模式下，如果 Istiod（控制面）或证书签发服务（如 cert-manager）发生故障，新启动的 Pod 可能无法获取有效证书，导致整个网格通信瘫痪。建议为证书管理组件设置独立的故障恢复机制。

3.6 模式选择决策树

以下决策树帮助你在实际项目中快速选择正确的 mTLS 模式：

3.7 小结

三种 mTLS 模式构成了 Istio 传输安全的三个阶梯：DISABLE 用于特殊场景，PERMISSIVE 作为默认与过渡模式，STRICT 是生产环境的最终目标。在实际项目中，建议遵循“先 PERMISSIVE 验证，再 STRICT 加固”的升级路径，并结合证书生命周期管理策略，确保 mTLS 升级过程平滑、安全、可回退。