K8S 生態週報| 幾乎影響全部 k8s 集羣的漏洞

「K8S 生態週報」內容主要包含我所接觸到的 K8S 生態相關的每週值得推薦的一些信息。歡迎訂閱知乎專欄 「k8s生態」。

Docker v19.03.11 發佈

距離 v19.03.10 發佈僅一週時間，Docker 又發佈了新版本 v19.03.11 。此版本是一個安全修復版本，經過禁用了 IPv6 路由地址廣播（RA）從而防止地址欺騙，對應的漏洞爲 CVE-2020-13401 。

在 Docker 的默認配置中，容器網絡接口是指向主機（veth 接口）的虛擬以太網連接，在此配置下，若是一個攻擊者能夠在容器中以 root 身份運行進程的話，那麼他是可使用 CAP_NET_RAW 能力，向主機任意發送和接收數據包的。

例如： 在容器內使用 root 用戶，能夠正常執行 ping 命令

(MoeLove) ➜  ~ docker run --rm -it -u root redis:alpine sh
/data # whoami
root
/data # ping -c 1 moelove.info
PING moelove.info (185.199.108.153): 56 data bytes
64 bytes from 185.199.108.153: seq=0 ttl=49 time=54.389 ms

--- moelove.info ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 54.389/54.389/54.389 ms

在容器內使用非 root 用戶，執行 ping 命令會提示無權限

(MoeLove) ➜  ~ docker run --rm -it -u redis redis:alpine sh
/data # whoami
redis
/data $ ping -c 1 moelove.info
PING moelove.info (185.199.109.153): 56 data bytes
ping: permission denied (are you root?)

若是沒有在主機上徹底禁用 IPv6 （經過內核參數 ipv6.disable=1）, 那麼主機上的網絡接口能夠本身進行配置。若是配置項爲 /proc/sys/net/ipv6/conf/*/forwarding == 0 那表示該接口禁用了 IPv6 轉發。全局的靜態配置能夠在如下位置看到：

(MoeLove) ➜  ~ cat /proc/sys/net/ipv6/conf/all/forwarding
1

另外，還有一個默認配置是關因而否接收 RA 消息的，若是配置項爲 /proc/sys/net/ipv6/conf/*/accept_ra == 1，則表示該接口默認接收 RA 消息。全局的靜態配置能夠在如下位置看到：

(MoeLove) ➜  ~ cat /proc/sys/net/ipv6/conf/all/accept_ra 
1

上述的兩個系統默認配置的組合，表示系統接受路由廣播（RA）消息，而且使用它配置 IPv6 網絡棧（SLAAC）。若是熟悉 IETF RFC 4861 的小夥伴應該知道，ICMPv6 RA 雖然本意是好的，但它確實存在安全風險。

在還沒有使用 IPv6 的網絡中，雙棧主機處於休眠狀態，並等待最終的 RA 消息來喚醒其 IPv6 鏈接。攻擊者能夠製做惡意的 RA 消息，獲取網絡中的雙協議節點以配置其 IPv6 地址，並利用攻擊者的系統做爲其默認的網關。這樣即可很簡單的實施中間人攻擊了。在 RFC 6104 中其實早就記錄過這個問題，也有不少相關的解決方案，此處就不展開了，涉及的東西太多了。

對應到這次漏洞中，若是攻擊者經過容器發送惡意 RA 消息（rogue RA），則能夠從新配置主機，將主機的部分或者所有 IPv6 通訊都重定向到攻擊者控制的容器。

即便以前沒有 IPv6 流量，若是 DNS 服務器返回 A（IPv4）和 AAAA（IPv6）記錄的話，不少 HTTP 庫將會首先嚐試進行 IPv6 鏈接，而後再回退到 IPv4 。這就爲攻擊者提供了製造響應的機會。

若是主機剛好有相似去年 apt 的 CVE-2019-3462 這種漏洞的話，則攻擊者即可能獲取主機權限。

整體而言，Docker 容器默認沒有配置 CAP_NET_ADMIN 能力，因此攻擊者沒法直接將其配置爲中間人攻擊的 IP，沒法使用 iptables 進行 NAT 或者 REDIRECT 流量，也不能使用 IP_TRANSPARENT。可是攻擊者仍然可使用 CAP_NET_RAW 能力，並在用戶空間實現 TCP/IP 堆棧。

聊完 Docker 相關的這個漏洞，這裏就順便展開聊聊相關的一些其餘問題吧。

與此漏洞相似的，受影響的還有 Kubernetes ， 但並非 Kubernetes 自身的漏洞，而是官方安裝源倉庫中，kubelet 依賴的 kubernetes-cni CNI 包，也存在漏洞 CVE-2020-10749

受影響版本爲：

• kubelet v1.18.0-v1.18.3
• kubelet v1.17.0-v1.17.6
• kubelet v1.16.11 以前版本

第三方組件相關的漏洞信息：

• Calico 和 Calico Enterprise (CVE-2020-13597) 漏洞信息 TTA-2020-001 可在此處 https://www.projectcalico.org... 查看；
• CNI Plugins v0.8.6 以前版本 （CVE-2020-10749），詳情見 https://github.com/containern...；
• Flannel 所有版本；
• Weave Net v2.6.3 以前版本；

如下第三方組件目前未受這次漏洞影響：

• Cilium
• Juniper Contrail Networking
• OpenShift SDN
• OVN-Kubernetes
• Tungsten Fabric

結合前面我對此漏洞的說明，想必你也看到了，解決此漏洞最簡單的方法是：

• 更新相關組件到最新（包含修復內容）的版本（截至目前，相關受影響組件中，除 Flannel 外，均已發佈新版原本解決此漏洞）；
• 能夠在系統中禁止接收 RA 消息（若是你不須要 RA 消息的話）；
• 也能夠禁用容器的 CAP_NET_RAW 能力，例如：

(MoeLove) ➜  ~ docker run --cap-drop CAP_NET_RAW --rm -it -u root redis:alpine sh
/data # ping -c 1 moelove.info
PING moelove.info (185.199.108.153): 56 data bytes
ping: permission denied (are you root?)

Docker Compose v1.26.0 發佈

Docker Compose 是一個很方便靈活的工具，你們應該不會陌生。前段時間 Docker 將 Compose 規範開源後，社區在逐步成長中。

本次發佈的 v1.26.0 中，包含了不少值得注意的內容：

• 添加了對 doker context 的支持，context 很是好用！Docker Inc. 在今年的 Docker Con 以前還和 Azure 達成了合做，加速從本地到雲的開發/部署等，具體操做上也都是經過 context 實現的；
• 支持經過 COMPOSE_COMPATIBILITY 環境變量配置其能力；

對此版本感興趣的朋友請參考其 ReleaseNote

Kube-OVN v1.2 發佈

Kube-OVN 是首次出如今「K8S 生態週報」中的項目，稍微作下介紹。它是一款基於 OVN 的 Kubernetes 網絡組件，經過將OpenStack領域成熟的網絡功能平移到Kubernetes，來應對更加複雜的基礎環境和應用合規性要求。

Kube-OVN主要具有五大主要功能：Namespace 和子網的綁定，以及子網間訪問控制，靜態IP分配，動態QoS，分佈式和集中式網關，內嵌 LoadBalancer。

本次發佈的 v1.2 中包含了如下重要更新：

• 開始支持 OVS-DPDK 以便於支持高性能 dpdk 應用；
• 支持使用 BGP 將 Pod IP 路由宣告到外部網絡；
• 在建立後，支持修改子網 CIDR （我我的以爲這個功能特別有用，網絡規劃也有動態調整的實際需求）；
• 當子網網關修改後，路由能夠自動更改；

對此版本感興趣的朋友請參考其 RelaseNote

上游進展

本週 Kubernetes v1.19.0-beta1 已經發布！

• #91113 和 #91481 在 kubectl create deployment 時，增長了 --port 的選項；

另外一個值得開心的變動來自 etcd :

• #11946 爲 etcd 添加了一個 --unsafe-no-fsync 的選項，能夠禁止文件同步。這對於本地開發/CI 測試都是很是好的！

---

歡迎訂閱個人文章公衆號【MoeLove】