「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/security-bulletins/ 查看；
- CNI Plugins v0.8.6 之前版本 （CVE-2020-10749），詳情見 https://github.com/containernetworking/plugins/pull/484；
- 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 已經發布！
另一個值得開心的變更來自 etcd :
-
#11946 爲 etcd 添加了一個
--unsafe-no-fsync的選項，可以禁止文件同步。這對於本地開發/CI 測試都是非常好的！
歡迎訂閱我的文章公衆號【MoeLove】