4.5　针对Kubernetes网络的中间人攻击案例

在3.4.3节中，我们展示了由单一容器发起的资源耗尽型攻击对宿主机及宿主机上其他容器可能造成的影响。在没有资源限制的容器环境下，不同容器之间很容易在资源层面互相影响。事实上，容器之间的影响不止在资源层面上有所表现，还体现在网络上——尤其是当其处于同一集群的时候。

在一般情况下，在使用Flannel作为集群网络插件时，我们部署的Kubernetes集群的网络架构如图4-12所示。

图4-12　常见的Kubernetes网络架构

从图4-12中可以解读出如下信息：

1）集群由多个节点组成。

2）每个节点上运行若干个Pod。

3）每个节点上会创建一个CNI网桥（默认设备名称为cni0）。

4）每个Pod存在于自己的网络命名空间中，通过虚拟网卡对Veth Pair设备与外界通信。

5）Veth Pair设备将创建两张虚拟网卡，分别位于Pod所在的网络命名空间中（对应图中Pod内部的eth0）和节点根网络命名空间中（对应图中每个节点上方根网络命名空间内的各个veth，如veth1056db9f），互为对端（Veth Peer），对于Veth Pair设备的两张虚拟网卡来说，从其中一张网卡发出的数据包，将直接出现在另一张网卡上。

6）每个Pod的eth0网卡的对端veth网卡“插”在cni0网桥上。

7）同一节点上的各Pod可以借助cni0网桥互相通信，不同节点之间需要借助额外的网络插件进行通信，如Flannel。

8）CoreDNS是整个Kubernetes集群的DNS服务器。

这样的网络会存在哪些安全问题呢？所有这些Pod似乎组成了一个小型的局域网络，这个网络中会不会存在中间人攻击的可能性呢？答案是可能存在。在默认配置下的Kubernetes集群中，假如攻击者借助Web渗透等方式攻破了某个Pod（如图4-12中的Web App Pod），他就有可能针对集群内的其他Pod发起中间人攻击，甚至可以基于此实现DNS劫持。

下面，我们就来看看这样一个发生在云原生环境中的ARP欺骗（ARP Spoofing）和DNS劫持（DNS Hijacking）场景[1]。

攻击者攻破Web App Pod之后，获得容器内部的root权限，通过ARP欺骗诱导另一个Pod（如Backend Pod），让其以为Web App Pod是集群的DNS服务器，进而使得Backend Pod在对外发起针对某域名（如example.com）的HTTP请求时首先向Web App Pod发起DNS查询请求。

攻击者在Web App Pod内部设置的恶意DNS服务器收到查询请求后返回了自己的IP地址，Backend Pod因此以为example.com域名的IP地址是Web App Pod的地址，于是向Web App Pod发起HTTP请求。

在收到HTTP请求后，攻击者在Web App Pod内设置的恶意HTTP服务器返回恶意响应给Backend Pod。至此，整个攻击过程结束，Backend Pod以为自己拿到了正确的信息，其实不然。

本节相关源码见随书Github仓库[2]。

[1] https://blog.aquasec.com/dns-spoofing-kubernetes-clusters。

[2] https://github.com/brant-ruan/cloud-native-security-book/tree/main/code/0405-云原生网络攻击。