【獨家】K8S漏洞報告 | 近期bug fix解讀

3月21日，Kubernetes社群透過Google Group頻道Kubernetes developer/contributor discussion釋出了安全漏洞CVE-2019-3874以及解決方法。

這個安全漏洞最早由紅帽的工程師Matteo Croce，Natale Vinto和Andrea Spagnolo發現。當Kubernetes中的Pod以Root使用者執行時，它可以繞過cgroup記憶體隔離，透過SCTP網路傳輸，建立一個潛在的DoS攻擊，此問題本身與Kubernetes無關，但是涉及到Kubernetes呼叫的核心模組。問題的嚴重性被定義為中等，社群建議將SCTP核心模組列入黑名單來規避此問題。使用者可以透過執行如下命令來測試是否會到此類攻擊。

modprobe sctp; lsmod | grep sctp

使用者可以透過執行如下命令來把SCTP列入核心模組的黑名單。

echo "install sctp /bin/true" > /etc/modprobe.d/sctp.conf

如果SCTP模組已經載入核心，則需要重啟機器來從核心中解除安裝SCTP模組。CVE-2019-3874安全漏洞的核心補丁正在開發中，但是透過將SCTP核心模組列入黑名單可以保護使用者永久免受此類攻擊。

CVE-2019-3874連結：

https://access.redhat.com/security/cve/cve-2019-3874

該問題的背景是#73587這個Issue。使用者在升級到v1.12.5之後，發現叢集內節點上Kubelet在執行一段時間後吃掉了所有的記憶體，導致節點故障。使用go tool pprof發現Client Go Metrics耗費了大部分的計算時間。這些Reflector Metrics並不是必不可少，該PR移除了如下的Metrics來解決記憶體洩漏的問題：

• reflector_items_per_list

• reflector_items_per_watch

• reflector_last_resource_version

• reflector_list_duration_seconds

• reflector_lists_total

• reflector_short_watches_total

• reflector_watch_duration_seconds

• reflector_watches_total

該問題的初始現象是Metrics Server獲取不到包含有InitContainers的Pod的Metrics。

根本原因在於退出的容器（如InitContainers）CPU和Memory都為Nil導致Metrics伺服器將跳過Pod的處理。具體是removeTerminatedContainer的實現忽略了cri提供的runtimeapi.Container和cadvisor提供的cadvisorapiv2.ContainerInfo的不同。

此問題的解決方法是在原有上報Nil的情況下，修改為上報退出容器的CPU和Memory為0。

該問題的背景是#72500這個Issue。在Kubelet重啟後，CSI Volume Plugin可能不會被重新註冊。這些Volume Plugin未註冊會相應地導致這些Plugin關聯的Volume的操作無法進行。解決辦法是在Kubelet重啟後，單獨提取一個csiClientGetter的Get()方法用於當初始化失敗時，能透過延遲CSI Client初始化的方式來重新註冊CSI Volume Plugin。

通常情況下大部分的Volume Plugin會去檢查Mount在Pod的Volume第一層級的目錄，但是對於CSI Plugin卻不是這樣，CSI Plugin可能會Mount在子目錄上。這個PR修改了Kubelet中VolumePath和MountPath引用的邏輯，實現對CSI的最佳化。

分類數量和佔比統計如下：

嚴重程度數量統計如下（橫座標5為最高，0為最低）：

如下為Kubernetes v1.13.5所有bug fix的彙總資訊：