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-云原生網絡攻擊。