北美時間11月26日，Kubernetes爆出嚴重安全漏洞，該漏洞由Rancher Labs聯合創始人及首席架構師Darren Shepherd發現。該漏洞CVE-2018-1002105（又名Kubernetes特權升級漏洞，https://github.com/kubernetes/kubernetes/issues/71411）被確認為嚴重性9.8分（滿分10分），惡意用戶可以使用Kubernetes API服務器連接到后端服務器以發送任意請求，并通過API服務器的TLS憑證進行身份驗證。這一安全漏洞的嚴重性更在于它可以遠程執行，***并不復雜，不需要用戶交互或特殊權限。

漏洞被發現并驗證后，Kubernetes快速響應并已經發布了修補版本v1.10.11、v1.11.5、v1.12.3和v1.13.0-rc.1。仍在使用Kubernetes v1.0.x至Kubernetes v1.9.x版本的用戶，被建議即刻停止并升級到修補版本。

本文由該漏洞的發現者、Rancher Labs聯合創始人及首席架構師Darren Shepherd所寫。他描述了自己發現這一漏洞的完整經過，剖析了問題的機制與原理，并分享了相應的解決方案以及他本人對Kubernetes、對開源社區的看法。

Rancher Labs聯合創始人及首席架構師 Darren Shepherd，同時也是Docker生態核心組織Docker治理委員會（DGAB）的全球僅有的四位個人頂級貢獻者之一。

這一切都始于2016年，當時Rancher Labs剛發布了Rancher 1.6。2016年年中的時候，亞馬遜發布了ALB，這是一個新的HTTP（7層）負載均衡器。ALB的設置比ELB容易得多，因此我們會建議用戶使用ALB。隨后很快，我們開始收到有關ALB后端設置失敗的報告，很多隨機請求只會得到401、403、404、503的報錯。然而，Rancher Labs的團隊無法重現這些錯誤，我們從社區成員那里得到的日志都沒有沒法成為參考。我們看到了HTTP請求和響應，但無法將其與代碼相關聯。那個時候，我們只好認為是因為ALB發布不久、產品本身可能存在些錯誤。除了ALB，我們之前從未遇到任何其他負載均衡器的問題。因此那時，我們只得最終告訴用戶不要使用ALB。

時間到了今年8月，又有Rancher社區成員向Rancher 2.1提交了同樣的問題（https://github.com/rancher/rancher/issues/14931）。仍和以前一樣，使用ALB會導致奇數401和403錯誤。這極大地引起了我的關注，因為Rancher 1.x和2.x之間沒有共同的代碼，而且ALB現在應該也已經相當成熟了。反復深入研究后，我發現問題與不處理非101響應和反向代理緩存TCP連接有關。若您想要真正理解這個問題，您必須了解TCP連接重用、websockets如何使用TCP連接以及HTTP反向代理。

在一種非常天真的HTTP方法中，客戶端將打開TCP socket，發送HTTP請求，讀取HTTP響應，然后關閉TCP socket。很快你就會發現你花了太多時間打開和關閉TCP連接。因此，HTTP協議具有內置的機制，以便客戶端可以跨請求重用TCP連接。

Websockets是雙向通信，其工作方式與HTTP請求／響應流不同。為了使用websockets，客戶端首先會發送HTTP升級請求，服務器會以HTTP 101 Switch Protocols響應來響應這一請求。收到101之后，TCP連接將專用于websocket。在TCP連接的剩余生命周期中，它是被認為是專用于該websocket連接的。這就意味著此TCP連接永遠不會被重新使用。

HTTP反向代理（負載均衡器是一種反向代理）從客戶端接收請求，然后將它們發送到不同的服務器。對于標準HTTP請求，它只寫入請求，讀取響應，然后將響應發送到客戶端。這種邏輯相當直接，而且Go也包含一個內置的反向代理：https://golang.org/pkg/net/http/httputil/#ReverseProxy。

相比之下Websockets就復雜一點。對于websocket，你必須查看請求，看到它是一個升級請求，然后發送請求，讀取101響應，然后劫持TCP連接，然后開始來回復制字節。對于反向代理，它不會在此之后查看連接的內容，它只是創建一個“廢棄管道”。標準Go庫中不存在此邏輯，許多開源項目都編寫了代碼來執行此操作。

關于錯誤所在，太長不看版的解釋是，Kubernetes在啟動“廢棄管道”之前沒有檢查101響應。在代碼的防御中，不檢查101是挺常見的。（這也是我們上文所說的Rancher用戶會發現的Rancher 1.x和Rancher 2.x的問題的原因，即使Rancher 1.x和Rancher 2.x使用的是完成不同的代碼。）錯誤的場景如下：

1. 客戶端發送websocket升級請求

2. 反向代理向后端服務器發送升級請求

3. 后端服務器以404響應

4. 反向代理啟動復制循環并將404寫入客戶端

5. 客戶端看到404響應并將TCP連接添加到“空閑連接池”

在這種情況下，如果客戶端重新使用TCP連接，它將向TCP連接寫入請求，它將通過反向代理中的“廢棄管道”并將其發送到前一個后端。通常這不會很糟糕，例如在負載均衡器的情況下，因為所有請求都會轉到同一組同類后端。但是，當反向代理是智能的，并且是由其執行身份驗證、授權和路由（即Kubernetes所做的全部工作）時，就會出現此問題。

因為101未被處理，所以客戶端最終使用TCP連接，該連接是對某些先前訪問的后端服務的“廢棄管道”。這將導致特權升級。問題是，Kubernetes將僅在反向代理中執行許多請求的授權。這意味著如果我執行一個授權失敗的websocket請求路由到一個kubelet，我可以保持與該kubelet的持久連接，然后運行我選擇的任何API命令，無論我是否被授權。例如，您可以在任何pod上運行exec并復制出secrets。因此，在這種情況下，已經授權的用戶基本上可以獲得對kubelet的完全API訪問（同樣的事情適用于通過kube-aggregation運行的服務）。

當您添加另一個反向代理時，會出現另一個問題。在這種情況下，您將HTTP負載均衡器放在Kubernetes API（非4層負載均衡器）之前。如果執行此操作，那個通過了身份驗證的、運行著“廢棄管道” 的TCP連接，將會被添加到一個任何用戶都可以訪問的空閑池中。那么，用戶A創建了TCP連接，之后用戶B仍可重新使用該連接。這樣一來，未經過身份驗證的用戶就可以訪問您的Kubernetes集群了。

此時你可能會感到恐慌，因為當然每個人都會在kube-apiserver前放置一個負載均衡器。唔……首先，您必須運行HTTP負載均衡器，而不是TCP負載均衡器。負載均衡器必須了解HTTP語義才能產生此問題。其次，幸運的是大多數反向代理并不關心101個回復。這就是為什么這個問題其實（在不少開源項目中）存在已久而未被發現的原因。大多數負載均衡器在看到升級請求而非101響應后不會重用TCP連接。所以，如果您會受到這一漏洞的影響，那么您的Kubernetes設置應該已經不可靠了，您應該能看到隨機失敗或無法完成的請求。至少我知道ALB就是這樣工作的，所以你升級到了已修補該漏洞的Kubernetes版本之前，不要使用ALB。

簡而言之，Kubernetes的這一安全漏洞會允許具有正確權限的任何經過身份驗證的用戶獲得更多權限。如果您正在運行硬件多租戶集群（內含不受信任的用戶），您確實應該擔心并且及時應對。如果您不擔心用戶主動互相***（大多數多租戶集群都是這樣），那么不要驚慌，只需升級到已修補該漏洞的Kubernetes版本即可。最壞的情況，如果真的有未經身份驗證的用戶可以進入您的集群，您的負載均衡器也有可能會阻止這種情況。只要不是將API暴露給世界，并且有在其上放置一些適當的ACL，也許你的集群也還是安全的。

對于使用Rancher Kubernetes平臺的用戶，你們更無須緊張。

對于把集群部署在內網的用戶，完全不需要過于擔心此問題，因為外部無法直接***。

通過Rancher2.0或RKE部署的kubernetes集群的用戶同樣不用過于擔心。因為通過Ranche2.0或RKE部署的集群默認是禁止和匿名用戶訪問。針對通過pod exec/attach/portforward權限提權問題，目前Kubernetes發布通用的修復方法是通過升級到指定Kubernetes版本來修復，針對此Rancher也已經發布修復程序，具體修復方法請參考：https://forums.rancher.com/t/rancher-security-advisory-kubernetes-cve-2018-1002105/12598

我深刻地感到，這次Kubernetes的這個安全漏洞的最初發現、修復和最終交付，證明了開源社區強大的生命力。我第一次發現這個問題，也是因為Rancher的非付費開源用戶給予我們的反饋。事實上，我們已經確認了這一問題并沒有影響Rancher 2.x的付費客戶，因為Rancher的HA架構恰好否定了ALB的行為，但我們還是去研究并解決了這個問題，因為我們太愛我們的開源用戶了。也正是在研究和修復這個問題的過程中，我發現了Kubernetes自身存在的安全隱患，并通過已建立的安全公開流程向Kubernetes社區反饋了該問題。