kiali 不主动检测加密，锁图标仅表示 mtls 策略已配置并下发至 envoy；需结合 istioctl authz check、envoy 配置及上游指标验证实际加密是否生效。
Kiali 本身不判断或标记加密状态，但能通过 mTLS 配置和 Envoy 指标间接反映服务间是否启用了双向 TLS —— 关键在于 Istio 的策略配置是否生效，而非 Kiali 主动“检测”加密。
确认 Istio 已启用 strict mTLS 并正确下发
Kiali 图形界面上显示的锁形图标（?）仅表示该连接被 DestinationRule 或 PeerAuthentication 显式要求 mTLS，且 Pilot 已将策略推送到对应 Envoy。它不验证实际流量是否真的加密（比如证书是否有效、握手是否成功）。
- 检查全局 mTLS 是否开启：
kubectl get peerauthentication default -n istio-system -o yaml，确认mtls.mode: STRICT - 检查目标服务是否有覆盖策略：
kubectl get peerauthentication -n <your-ns></your-ns>，避免命名空间级策略覆盖了 strict 模式 - 确保
DestinationRule中设置了trafficPolicy.tls.mode: ISTIO_MUTUAL，否则即使 PeerAuthentication 开启，Sidecar 仍可能降级为明文通信
Kiali 图形中如何识别 mTLS 连接
在 Graph 页面中，mTLS 状态只在边（连线）上以小锁图标形式出现，且仅当满足两个条件时才显示：
- 该调用路径上的服务对（source → destination）都已注入 Sidecar
- 双方均受有效的
PeerAuthentication+DestinationRule约束，且策略未被覆盖或拒绝
注意：Service 节点之间若无锁图标，常见原因不是“没加密”，而是调用未经过 Sidecar（如 ClusterIP 直连、DNS 解析绕过 FQDN）、或目标服务未启用自动注入、或策略作用域不匹配（例如策略在 istio-system，但服务在 default）。
为什么看不到锁图标？先查这三处
锁图标缺失 ≠ 流量未加密，但大概率说明 mTLS 策略未按预期生效。高频排查点：
-
istioctl authz check <pod-name> -n <ns></ns></pod-name>：确认 Pod 的 Envoy 是否收到 mTLS 策略（输出中应含tlsContext字段） -
kubectl get sidecar -n <ns></ns>：检查是否存在限制出口流量的Sidecar资源，它可能屏蔽了 mTLS 所需的 outbound 配置 - 查看 Kiali 右上角「Display」菜单是否勾选了
Show Security—— 默认关闭，不勾选就完全不渲染锁图标
加密流量的可观测性局限在哪
Kiali 展示的延迟、错误率、QPS 全部来自 Envoy 访问日志和指标，而这些数据在 mTLS 启用后依然可采集（因为解密发生在 Envoy 内部，日志记录的是解密后的 HTTP 层）。但以下信息 Kiali 无法提供：
- 证书有效期、CN/SAN 匹配结果、握手失败具体原因（需查
istio-proxy容器日志或用istioctl proxy-config secret） - 是否使用了自签名 CA、是否启用了 SDS（Kiali 不暴露证书管理细节）
- 非 HTTP/gRPC 协议（如 TCP）的 mTLS 状态，Kiali 当前仅对七层协议做安全状态渲染
真正验证加密是否跑通，不能只看锁图标；得结合 istioctl experimental authz check 输出、Envoy config dump 中的 tls_context、以及实际请求的 upstream_canary 指标是否稳定 —— 锁图标只是策略就绪的快照，不是运行时加密的实时探针。
