Istio Ambient mTLS的流程讲解

1. 客户端 → 云负载均衡 (LoadBalancer)

• 外部客户端（浏览器、API 客户端等）发起 HTTPS/TLS 请求。
• 云厂商的 LoadBalancer（如 AWS ALB、GCP HTTP(S) LB）在第 4 层或第 7 层将流量转发到集群中部署的 Ambient Ingress Gateway。

2. LoadBalancer → Envoy Ingress Gateway

• 前端 TLS 连接在这里依然端到端保持加密（可选配置：在此处也可做 Terminate，但常建议在 Gateway 保留 TLS 透传，然后在 Gateway 处结合 zTunnel 做统一管理）。
• Envoy Ingress Gateway（部署为 Kubernetes Service）接收原始 TLS 流量。

3. Envoy Ingress Gateway → zTunnel 出站代理

• 在 Ambient 模式下，Ingress Gateway 会把解密（或透传）的流量交给同节点上的 zTunnel 出站代理（DaemonSet 形式部署）。
• 这里将根据目标服务的身份，使用 双向 mTLS（由 zTunnel 与目标入站代理协商）将流量重新加密。

4. zTunnel 出站代理 → zTunnel 入站代理

• zTunnel 出站代理通过 mTLS 隧道与目标 Pod 所在节点上的 zTunnel 入站代理 建立连接。
• 双向 TLS 使用 Istiod 下发的 SPIFFE X.509 证书，保证两端 Envoy 代理的身份认证与流量加密。

5. zTunnel 入站代理 → 应用 Pod

• 入站代理在解密后将明文 HTTP/gRPC 请求通过本地 iptables 拦截 或透明代理（TPROXY）转发给真正的应用 Pod。
• Pod 内部无需 Envoy Sidecar，直接接收标准 HTTP/gRPC 流量。

6. Istiod 证书管理

• Istiod 负责为所有 zTunnel 代理颁发和轮换短期 SPIFFE 证书（默认 24 小时一次），并通过 SDS（Secret Discovery Service）下发到各代理节点。
• zTunnel 代理在启动或证书到期时，会自动向 Istiod 进行证书拉取与更新，无需人工干预。