使用ksniff和Wireshark在Kubernetes中验证service mesh TLS

除了来自[HashiCorp](https://www.hashicorp.com/)的[Nic Jackson](https://twitter.com/sheriffjackson)，我最近在几次会议和网络研讨会上介绍了在现代应用程序中需要跨end-to-end或“[user to service](https://www.cncf.io/event/securing-cloud-native-communication-from-end-user-to-service/)”的传输级加密。从用户浏览器到应用边缘的TLS加密（和termination）一直是API网关、CDNS和edge proxies的长期feature，但是直到最近，service mesh技术才使得TLS服务于服务流量成为我们大多数人的现实方法。

许多service mesh都承诺实现低接触TLS，允许使用人员通过一个配置选项或一个几行的YAML来启用它。但是，您如何知道集群间的通信量实际上已经被成功加密了？当然，您可以在Kubernetes集群中运行的Pod中启动tcpdump，但这可能很难管理，特别是对于那些不太熟悉Linux工具的人。在最近一系列的service mesh调查和TLS调试之后，我偶然遇到了Eldad Rudich的[ksniff](https://github.com/eldadru/ksniff) kubectl插件，这已经被证明是一个非常有用的工具，可以用来检查集群内部的流量。

现在我将分享使用ksniff的一些经验教训，并根据我最近对API网关与service mesh的第一个内部跳之间的TLS通信的调查，提供一些示例。

ksniff — 拥有Wireshark的所有优点，可在Kubernetes中运行

根据该项目的GitHub repo，ksniff是一个“使用tcpdump和wireshark来轻松嗅探kubernetes pod的插件”。我使用tcpdump和Wireshark来检查网络流量已经很多年了，但是我发现在Kubernetes中使用它有些困难。而使用像ksniff这样的简单的kubectl插件，几乎消除了配置两个流量监听工具的所有手动工作。

您可以使用kubectl插件包管理器krew安装ksniff：

$ kubectl krew install sniff

现在，您已经安装了工具，让我们进行演示。

您还需要在本地计算机上安装Wireshark。我通常通过网站下载完成此操作，但是您也可以通过apt和brew等大多数软件包管理器找到Wireshark。

我以前曾手动安装了ksniff（因为我想使用krew软件包中当时不提供的功能），这很容易做到，并且也有据可查。

Sniffing 未加密的 edge-to-service 流量

我已经通过Helm 将Ambassador API网关和HashiCorp的Consulservice mesh部署到GKE托管的Kubernetes集群中。由于Ambassador和Consul之间的集成，我可以向通过Ambassador（正在管理GCP负载均衡器）公开的API端点发出请求，并可以进行动态路由此请求，通过TLS连接将其从网关路由到任何内部服务。我还可以使用Consul作为Ambassador的一个简单的服务发现机制，它允许动态路由流量，但不使用传输加密。我们先这样做，这样就可以通过ksniff看到未加密的通信量。

我已经安装了Ambassador，Consul和“quote of the moment (QOTM)（QOTM）”服务，如gateway/mesh集成文档前半部分所述。在集群中，我看到以下服务正在运行：

我可以向通过/qotm-consul/端点公开的QOTM应用程序发出外部请求，该请求通过Ambassador和Consul进行路由