43. 验证您的 mTLS 流量

默认情况下，Linkerd 自动启用双向传输层安全性 (mTLS) 用于网格化 Pod 之间的 TCP 流量，通过在 Linkerd 代理之间建立和验证安全的私有 TLS 连接。 只需添加你的服务 到 Linkerd，Linkerd 会处理剩下的事情。

Linkerd 的自动 mTLS 以对应用程序完全透明的方式完成。 当然，有时能够验证 mTLS 是否有效是有帮助的！

使用 linkerd viz edges 验证 mTLS

要验证 mTLS 是否正常工作， 您可以使用 linkerd viz edges 命令查看由 Linkerd 管理的服务之间的 TCP 连接摘要。 例如：

linkerd viz -n linkerd edges deployment

输出将如下所示：

SRC          DST                      SRC_NS        DST_NS    SECURED
prometheus   linkerd-controller       linkerd-viz   linkerd   √
prometheus   linkerd-destination      linkerd-viz   linkerd   √
prometheus   linkerd-identity         linkerd-viz   linkerd   √
prometheus   linkerd-proxy-injector   linkerd-viz   linkerd   √
prometheus   linkerd-sp-validator     linkerd-viz   linkerd   √

在这个例子中，一切都成功地进行了 mTLS， 并且 CLIENT 和 SERVER 列表示使用的身份， 格式为 service-account-name.namespace。 （有关这些身份含义的更多信息， 请参阅 Linkerd 的自动 mTLS 文档。） 如果自动升级与 mTLS 的连接出现问题，MSG 字段将包含原因。

使用 linkerd viz tap 验证 mTLS

除了依赖聚合，还可以实时观察请求和响应，以了解什么是得到 mTLS 的。 我们可以使用 linkerd viz tap 命令来采样实时请求数据。 除了依赖聚合，还可以实时观察请求和响应，以了解什么正在获得 mTLS。 我们可以使用 linkerd viz tap 命令 来采样实时请求数据。

linkerd viz -n linkerd tap deploy

具体来看控制平面，将有两种主要类型的输出。

req id=0:0 proxy=in  src=10.42.0.1:60318 dst=10.42.0.23:9995 tls=no_tls_from_remote :method=GET :authority=10.42.0.23:9995 :path=/ready
rsp id=0:0 proxy=in  src=10.42.0.1:60318 dst=10.42.0.23:9995 tls=no_tls_from_remote :status=200 latency=267µs
end id=0:0 proxy=in  src=10.42.0.1:60318 dst=10.42.0.23:9995 tls=no_tls_from_remote duration=20µs response-length=3B

这些是 Kubernetes readiness probe的调用。 由于探测是从不在网格中的 kubelet 启动的，因此没有身份并且这些请求不是 mTLS， 如 tls=no_tls_from_remote 消息所示。

对控制平面的其他请求是 TLS 的：

ireq id=2:1 proxy=in  src=10.42.0.31:55428 dst=10.42.0.22:9995 tls=true :method=GET :authority=10.42.0.22:9995 :path=/metrics
rsp id=2:1 proxy=in  src=10.42.0.31:55428 dst=10.42.0.22:9995 tls=true :status=200 latency=1597µs
end id=2:1 proxy=in  src=10.42.0.31:55428 dst=10.42.0.22:9995 tls=true duration=228µs response-length=2272B

此连接来自网格中的 Prometheus，因此请求会自动进行 mTLS，如 tls=true 输出所示。

使用 tshark 验证 mTLS

验证 mTLS 的最后一种方法是查看集群内的原始网络流量。

Linkerd 包含一个 debug sidecar，它带有一系列命令， 可以更轻松地验证和调试服务网格本身。 例如，使用我们的 emojivoto demo application， 我们可以通过运行以下命令添加 debug sidecar：

curl -sL https://run.linkerd.io/emojivoto.yml \
  | linkerd inject --enable-debug-sidecar - \
  | kubectl apply -f -

然后我们可以直接在 voting 服务中的一个 pod 的调试容器中建立一个远程 shell：

kubectl -n emojivoto exec -it \
    $(kubectl -n emojivoto get po -o name | grep voting) \
    -c linkerd-debug -- /bin/bash

一旦我们进入 debug sidecar， 就可以使用内置的 tshark 命令来检查网络接口上的原始数据包。例如：

tshark -i any -d tcp.port==8080,ssl | grep -v 127.0.0.1

这告诉 tshark 端口 8080 可能是 TLS 的，并忽略 localhost（因为该流量将始终未加密）。 输出将显示自动 mTLS 的主要应用程序流量。

  133 11.391540872    10.4.0.17 → 10.4.0.23    TCP 68 46766 → 4191 [ACK] Seq=557 Ack=3942 Win=1329 Len=0 TSval=3389590636 TSecr=1915605020
  134 12.128190076    10.4.0.25 → 10.4.0.23    TLSv1.2 154 Application Data
  140 12.129497053    10.4.0.23 → 10.4.0.25    TLSv1.2 149 Application Data
  141 12.129534848    10.4.0.25 → 10.4.0.23    TCP 68 48138 → 8080 [ACK] Seq=1089 Ack=985 Win=236 Len=0 TSval=2234109459 TSecr=617799816
  143 13.140288400    10.4.0.25 → 10.4.0.23    TLSv1.2 150 Application Data
  148 13.141219945    10.4.0.23 → 10.4.0.25    TLSv1.2 136 Application Data

总结

在本指南中，我们提供了几种不同的方法来验证 Linkerd 是否能够自动将连接升级到 mTLS。 请注意，Linkerd 可能无法进行此升级的原因有多种— 请参阅Linkerd 自动 mTLS 文档的“注意事项和未来工作”部分— 因此，如果出于安全目的依赖 Linkerd，则此类验证可能具有指导意义。