4. 全局 mTLS 策略配置：通过 PeerAuthentication 资源实现全局 STRICT mTLS
在 Istio 服务网格中，PeerAuthentication 是控制服务间双向 TLS（mTLS）策略的核心资源。通过配置全局级别的 PeerAuthentication，运维团队可以强制网格内所有 Sidecar 之间的流量都使用 STRICT 模式，即拒绝任何非 mTLS 的明文请求。这是实现零信任网络架构的基础步骤。
4.1 PeerAuthentication 策略层级与生效规则
PeerAuthentication 策略遵循 网格 → 命名空间 → 工作负载 的继承与覆盖规则。全局策略通常在网格根命名空间（istio-system）中定义，作为整个网格的默认行为。
| 层级 | 配置位置 | 作用范围 | 优先级 |
|---|---|---|---|
| 网格级（全局） | istio-system 命名空间 |
所有启用了 Sidecar 的工作负载 | 最低（默认） |
| 命名空间级 | 目标命名空间 | 该命名空间下的所有工作负载 | 中 |
| 工作负载级 | 目标工作负载所在命名空间，通过 selector 匹配 |
匹配特定标签的工作负载 | 最高 |
最佳实践： 建议先在
istio-system 中部署全局 STRICT 策略，然后通过命名空间级或工作负载级的 PERMISSIVE 策略逐步放行遗留系统，实现渐进式迁移。
4.2 全局 STRICT mTLS 配置示例
以下 YAML 清单定义了一个全局 PeerAuthentication 资源，将整个网格的 mTLS 模式设置为 STRICT：
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default-global-strict
namespace: istio-system
spec:
mtls:
mode: STRICT关键说明：
- 命名空间： 必须部署在
istio-system中，Istio 控制面会将其识别为网格范围的默认策略。 - 名称： 建议使用
default或default-global等明确标识全局性的名称。 - mode: STRICT：强制要求所有入站连接都使用 TLS 握手，非 mTLS 请求将被拒绝并返回 503 错误。
4.3 全局 STRICT 策略的流量交互流程
下图展示了在全局 STRICT 模式下，服务 A 与服务 B 之间的通信路径。所有 Sidecar 代理之间的连接都必须经过双向 TLS 认证。
4.4 验证全局 STRICT 策略生效
部署策略后，可以通过以下步骤验证其是否生效：
- 检查策略状态： 使用
kubectl get peerauthentication -n istio-system确认资源已创建。 - 测试明文请求： 从网格内任意 Pod 发起 HTTP 请求到另一个服务，如果未使用 TLS，请求应失败。
- 查看 Sidecar 日志： 在目标服务的 Sidecar 日志中搜索
mTLS handshake error或plaintext request rejected等关键字。
验证命令示例：
# 从 sleep Pod 向 httpbin 服务发送明文请求
kubectl exec deploy/sleep -- curl -s -o /dev/null -w "%{http_code}" http://httpbin.default:8000/get
# 预期输出：000 或 503（表示连接被拒绝）
# 若输出 200，则说明策略未生效或存在 PERMISSIVE 覆盖4.5 全局 STRICT 策略的注意事项
| 注意事项 | 说明 |
|---|---|
| 网格外服务 | 全局 STRICT 仅影响网格内启用了 Sidecar 的工作负载。对于通过 ServiceEntry 访问的外部服务，需要单独配置 DestinationRule 的 TLS 设置。 |
| 控制面组件 | Istiod 自身与 Sidecar 之间的通信（如 xDS 推送）默认使用 mTLS，不受 PeerAuthentication 影响。 |
| 渐进式迁移 | 对于已有大量非 mTLS 流量的网格，直接切换到全局 STRICT 可能导致大面积中断。建议先使用 PERMISSIVE 模式收集流量，再逐步收紧。 |
| 策略冲突 | 如果命名空间或工作负载级存在 PERMISSIVE 策略，会覆盖全局 STRICT 设置。使用 istioctl analyze 检查策略冲突。 |
4.6 全局 STRICT 与 PERMISSIVE 的对比
理解两种模式的差异有助于制定合理的迁移计划：
| 特性 | STRICT 模式 | PERMISSIVE 模式 |
|---|---|---|
| 明文请求 | 拒绝 | 允许 |
| mTLS 请求 | 强制 | 允许（优先使用） |
| 安全等级 | 高（零信任） | 中（兼容过渡） |
| 性能开销 | 固定 TLS 握手 | 额外协商开销 |
| 适用场景 | 生产环境、合规要求 | 迁移期、遗留系统 |
安全警告： 在金融、医疗等合规敏感环境中，全局 STRICT 是满足监管要求的必要配置。切勿在生产环境中长期使用 PERMISSIVE 模式，否则会暴露明文流量风险。
4.7 全局 STRICT 策略的故障排查
当全局 STRICT 策略导致意外中断时，可以按以下步骤排查：
- 确认策略是否被覆盖： 使用
istioctl x describe pod <pod-name>查看该 Pod 实际生效的 PeerAuthentication 策略。 - 检查证书是否存在： 确认 Sidecar 已成功从 Istiod 获取到证书。查看 Sidecar 日志中的
certificate相关条目。 - 验证 mTLS 是否启用： 使用
istioctl authn tls-check <source-pod> <destination-service>命令检查两个端点之间的 mTLS 状态。
通过以上配置与验证步骤，运维团队可以安全、可控地在 Istio 网格中实施全局 STRICT mTLS 策略，为后续的证书管理与零信任架构奠定基础。