只加密我的服务？ 🔒 Istio mTLS，盲目使用STRICT模式会出大问题的原因

在引入服务网格，特别是Istio时，最先期待的事情之一就是强大的“相互TLS (mTLS)”加密。加密所有服务间的通信，即使数据在传输过程中被截获，内容也无法被知晓，光是想想就觉得安心。💪

因此，许多人在应用Istio后，会立即将安全设置更改为STRICT模式。“既然要做，就用最强的安全！”这是他们的想法。但是，您知道吗？这种仓促的决定反而可能导致整个服务瘫痪。

今天，我们将深入探讨为什么不应该盲目应用STRICT模式，以及为了更安全、更灵活的迁移策略，作为关键的PERMISSIVE模式。

---

🤔 “我们的服务都在网格内，这样不是没问题吗？”

当然，如果您的开发环境或所有服务从一开始就都在Istio服务网格内启动，那么STRICT模式是一个绝佳的选择。STRICT模式顾名思义，是一种“严格”的策略，只允许通过Istio代理（Sidecar）进行mTLS加密的流量。

此策略可以用YAML表示如下：

# apiVersion: security.istio.io/v1beta1
# kind: PeerAuthentication
# metadata:
#   name: "default-strict-mtls"
#   namespace: "your-namespace"
# spec:
#   mtls:
#     mode: STRICT

STRICT模式在网格内部服务之间通信时完全没有问题。因为它们都带有Sidecar，并且知道如何通过mTLS进行通信。

然而，现实世界的系统并非如此理想。😥

💥 真正的问题始于“网格外部”

实际的运营环境通常面临以下复杂情况：

1. 渐进式迁移：一次性将所有服务迁移到服务网格几乎是不可能的。部分服务在网格内，部分仍在外部的过渡状态会持续很长时间。
2. 遗留系统：存在一些没有计划迁移到服务网格的旧遗留系统。
3. 外部解决方案：有时需要从网格外部直接检查内部服务的状态，例如监控系统（如Prometheus）或特定的健康检查系统。

在这种情况下，如果应用STRICT模式会发生什么？

情景示例：假设网格外部的`legacy-monitor`调用网格内部`user-service`的健康检查端点（/healthz）。

• user-service: 位于Istio网格内，并应用了STRICT模式。（只允许mTLS通信）
• legacy-monitor: 位于网格外部，因此没有Istio Sidecar。（尝试明文、Plaintext HTTP通信）

结果：`legacy-monitor`发送的明文HTTP请求会被`user-service`的Sidecar阻止。Sidecar会切断连接，说：“嗯？这不是mTLS加密的请求？我不能放行！”💥

# 在 legacy-monitor Pod 中执行
$ curl http://user-service.your-namespace.svc.cluster.local/healthz

# 预期结果
curl: (56) Recv failure: Connection reset by peer

最终，监控系统会判断服务已宕机并发送故障警报。即使服务本身运行良好！

---

🌉 过渡期的明智之桥，PERMISSIVE模式

为了避免这种混乱，PERMISSIVE（允许）模式应运而生。

PERMISSIVE模式是一种灵活的策略，同时接受mTLS加密流量和明文流量。这就像机场的安检口，同时运营国内旅客专用通道和国际旅客专用通道。✈️

YAML配置非常简单，只需更改`mode`即可。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default-permissive-mtls"
  namespace: "your-namespace"
spec:
  mtls:
    mode: PERMISSIVE # <--- 就是这里！

在PERMISSIVE模式下，工作负载的行为如下：

• 网格内部服务间的通信：如果对方也有Sidecar，它们会自动通过mTLS加密通信。（保持安全 ✅）
• 来自网格外部的通信：即使对方没有Sidecar并发送明文请求，也会被接受。（保持兼容性 ✅）

完整的迁移旅程 🗺️

利用PERMISSIVE模式，您可以安全地将整个系统无中断地切换到服务网格。

第一阶段：引入与转换 (PERMISSIVE)

• 在Istio网格内部署新服务，并将`PeerAuthentication`设置为PERMISSIVE模式。
• 结果：
• 网格内的服务之间通过mTLS安全通信。
• 网格外的遗留服务也像以前一样，通过明文无问题地通信。
• 系统稳定运行，无中断。😌

第二阶段：稳定与验证

• 仔细检查所有服务是否已进入网格，以及所有外部依赖是否已消除。
• 通过Kiali等仪表板确认所有流量都显示为锁（🔒）图标（mTLS），从而获得信心。

第三阶段：最终强化 (STRICT)

• 当所有服务都成功在网格内安顿下来，并且判断不再需要允许外部明文流量时，此时将`PeerAuthentication`切换到STRICT模式。
• 结果：现在我们的服务网格将成为一个坚固的堡垒，从根本上阻止来自外部的未加密访问。🏰

---

✨ 结论：因地制宜的策略才是最佳安全

Istio的STRICT模式无疑是一个强大而理想的安全目标。然而，正如所有旅程都有过程一样，在向服务网格过渡的过程中，PERMISSIVE模式扮演着不可或缺的“垫脚石”角色。

与其盲目坚持最强的设置，不如理解当前系统的构成和迁移阶段，并选择与之相符的灵活策略，这才是构建真正稳定系统的途径。

您的服务网格目前处于哪个阶段？为了防止潜在的故障，请立即检查您的`PeerAuthentication`设置！

---