資訊專欄INFORMATION COLUMN
摘要：北美時間月日，爆出嚴重安全漏洞，該漏洞由聯合創始人及首席架構師發現。反復深入研究后，我發現問題與不處理非響應和反向代理緩存連接有關。問題是，將僅在反向代理中執行許多請求的授權。大多數負載均衡器在看到升級請求而非響應后不會重用連接。
北美時間11月26日，Kubernetes爆出嚴重安全漏洞，該漏洞由Rancher Labs聯合創始人及首席架構師Darren Shepherd發現。該漏洞CVE-2018-1002105（又名Kubernetes特權升級漏洞，https://github.com/kubernetes...）被確認為嚴重性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）的全球僅有的四位個人頂級貢獻者之一。
Amazon ALB的問題
這一切都始于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/ra...）。仍和以前一樣，使用ALB會導致奇數401和403錯誤。這極大地引起了我的關注，因為Rancher 1.x和2.x之間沒有共同的代碼，而且ALB現在應該也已經相當成熟了。反復深入研究后，我發現問題與不處理非101響應和反向代理緩存TCP連接有關。若您想要真正理解這個問題，您必須了解TCP連接重用、websockets如何使用TCP連接以及HTTP反向代理。
TCP連接重用
在一種非常天真的HTTP方法中，客戶端將打開TCP socket，發送HTTP請求，讀取HTTP響應，然后關閉TCP socket。很快你就會發現你花了太多時間打開和關閉TCP連接。因此，HTTP協議具有內置的機制，以便客戶端可以跨請求重用TCP連接。
WebSockets
Websockets是雙向通信，其工作方式與HTTP請求／響應流不同。為了使用websockets，客戶端首先會發送HTTP升級請求，服務器會以HTTP 101 Switch Protocols響應來響應這一請求。收到101之后，TCP連接將專用于websocket。在TCP連接的剩余生命周期中，它是被認為是專用于該websocket連接的。這就意味著此TCP連接永遠不會被重新使用。
HTTP反向代理
HTTP反向代理（負載均衡器是一種反向代理）從客戶端接收請求，然后將它們發送到不同的服務器。對于標準HTTP請求，它只寫入請求，讀取響應，然后將響應發送到客戶端。這種邏輯相當直接，而且Go也包含一個內置的反向代理：https://golang.org/pkg/net/ht...。
相比之下Websockets就復雜一點。對于websocket，你必須查看請求，看到它是一個升級請求，然后發送請求，讀取101響應，然后劫持TCP連接，然后開始來回復制字節。對于反向代理，它不會在此之后查看連接的內容，它只是創建一個“廢棄管道”。標準Go庫中不存在此邏輯，許多開源項目都編寫了代碼來執行此操作。
錯誤所在
關于錯誤所在，太長不看版的解釋是，Kubernetes在啟動“廢棄管道”之前沒有檢查101響應。在代碼的防御中，不檢查101是挺常見的。（這也是我們上文所說的Rancher用戶會發現的Rancher 1.x和Rancher 2.x的問題的原因，即使Rancher 1.x和Rancher 2.x使用的是完成不同的代碼。）錯誤的場景如下：
客戶端發送websocket升級請求
反向代理向后端服務器發送升級請求
后端服務器以404響應
反向代理啟動復制循環并將404寫入客戶端
客戶端看到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保駕護航
對于使用Rancher Kubernetes平臺的用戶，你們更無須緊張。
對于把集群部署在內網的用戶，完全不需要過于擔心此問題，因為外部無法直接入侵。
通過Rancher2.0或RKE部署的kubernetes集群的用戶同樣不用過于擔心。因為通過Ranche2.0或RKE部署的集群默認是禁止和匿名用戶訪問。針對通過pod exec/attach/portforward權限提權問題，目前Kubernetes發布通用的修復方法是通過升級到指定Kubernetes版本來修復，針對此Rancher也已經發布修復程序，具體修復方法請參考：https://forums.rancher.com/t/...
感謝開源
我深刻地感到，這次Kubernetes的這個安全漏洞的最初發現、修復和最終交付，證明了開源社區強大的生命力。我第一次發現這個問題，也是因為Rancher的非付費開源用戶給予我們的反饋。事實上，我們已經確認了這一問題并沒有影響Rancher 2.x的付費客戶，因為Rancher的HA架構恰好否定了ALB的行為，但我們還是去研究并解決了這個問題，因為我們太愛我們的開源用戶了。也正是在研究和修復這個問題的過程中，我發現了Kubernetes自身存在的安全隱患，并通過已建立的安全公開流程向Kubernetes社區反饋了該問題。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/32788.html
摘要：首爆嚴重安全漏洞，嚴重性分于昨晚爆出嚴重安全漏洞，該漏洞由聯合創始人及首席架構師發現。其他功能更新對第三方設備監控插件的支持該功能目前被引入為功能。拓撲感知卷調度該功能現成為狀態。 K8S首爆嚴重安全漏洞，嚴重性9.8分 Kubernetes于昨晚爆出嚴重安全漏洞，該漏洞由Rancher Labs聯合創始人及首席架構師Darren Shepherd發現。該漏洞CVE-2018-1002...
摘要：今天，發布了一系列補丁版本，修復新近發現的兩個安全漏洞命令安全漏洞和端口映射插件漏洞。因為端口映射插件是嵌入到版本中的，只有升級至新版本的才能解決此問題。現在修復之后，將端口映射插件的規則由最優先變為附加，則可以讓流量優先由規則處理。 今天，Kubernetes發布了一系列補丁版本，修復新近發現的兩個安全漏洞CVE-2019-1002101（kubectl cp命令安全漏洞）和CVE-...
摘要：本文將介紹通過強身份驗證如何確保企業的集群免受外部攻擊。服務器雖然面向公開，但是受到證書身份驗證的保護。年年底被爆出的首個嚴重安全漏洞，就是由聯合創始人及首席架構師發現的。 毋庸置疑，K8s已經成為云容器編排系統的標準，但是，如果缺乏K8s環境相關的安全問題認識的話，會致使各種組件暴露在網絡集群內外的攻擊之下。本文將介紹通過強身份驗證如何確保企業的K8s集群免受外部攻擊。 showIm...
摘要：爆出中等嚴重性安全漏洞拒絕服務漏洞。本文將進行漏洞解讀和情景再現，并分享漏洞修復方案，用戶來看應對之策了漏洞美國當地時間年月日，社區發布了拒絕服務的漏洞，即有寫入權限的用戶在寫入資源時會導致過度消耗資源，此漏洞被評級為中等嚴重性。 Kubernetes爆出中等嚴重性安全漏洞——Kubernetes API Server拒絕服務漏洞CVE-2019-1002100。 本文將進行漏洞解讀和...
摘要：年月阿里巴巴高級技術專家許真恩慕義發布了首個開源版本，作為的開源實現截止目前已經更新到了的大版本，并且支持大規模生產版本。支持目前幾乎所有主流的微服務生態體系。 前言 6月份阿里開源的Nacos出了1.0.1版本，從去年7月份第一個release版本到現在一直在默默關注 官方的版本規劃為：Nacos從0.8.0開始支持生產可用，1.0版本可大規模生產可用，2.0版本接入k8s、Spri...
閱讀 826·2021-11-22 11:59
閱讀 3230·2021-11-17 09:33
閱讀 2308·2021-09-29 09:34
閱讀 1941·2021-09-22 15:25
閱讀 1955·2019-08-30 15:55
閱讀 1321·2019-08-30 15:55
閱讀 530·2019-08-30 15:53
閱讀 3346·2019-08-29 13:55
