Kubernetes儀表盤和外部IP代理漏洞及應(yīng)對之策

everfly 發(fā)布于2019-07-01 16:59 / 2260人閱讀

摘要：近期，儀表盤和外部代理接連被發(fā)現(xiàn)存在安全問題。本文將更深入解讀這兩個安全漏洞的原理會對您的部署造成的影響以及相應(yīng)的應(yīng)對之策。在中，儀表盤作為每個集群環(huán)境的一部分包含在內(nèi)但是，部署不受影響，因為充當(dāng)了儀表盤的身份驗證授權(quán)和代理。

近期，Kubernetes儀表盤和外部IP代理接連被發(fā)現(xiàn)存在安全問題。針對這兩個漏洞，Kubernetes發(fā)布了相應(yīng)的補丁版本供會受漏洞影響的用戶解決問題。本文將更深入解讀這兩個安全漏洞的原理、會對您的Kubernetes部署造成的影響以及相應(yīng)的應(yīng)對之策。

通過kubernetes儀表盤訪問自定義TLS證書

Kubernetes儀表盤漏洞（CVE-2018-18264）會影響v1.10.0或更早的儀表盤版本。因為這一漏洞，用戶可以“跳過”登錄過程，假設(shè)配置的服務(wù)帳戶，最后獲得儀表盤所使用的自定義TLS證書。如果您已將Kubernetes儀表盤配置為需要登錄并將其配置為使用自定義TLS證書，那么這一漏洞會影響到您，您需要及時注意。

該漏洞的運作原理

此漏洞可以分為兩部分來解釋。

第一個是，因為登陸時用戶可以選擇“跳過”這一選項，那么任何用戶都可以繞過登錄過程，該過程在v1.10.0或更早版本中始終默認啟用。這樣一來，用戶就完全跳過登錄過程并能使用儀表盤配置的服務(wù)帳戶。

第二個是，使用儀表盤配置的服務(wù)帳戶，必須最低限度地有權(quán)限訪問自定義TLS證書（以secret的形式存儲）。未經(jīng)身份驗證的登錄，加上儀表板使用配置的服務(wù)帳戶來檢索這些secret的能力，組合在一起的結(jié)果就是這一安全問題。

使用儀表盤v1.10.1補丁時，默認情況下將不再啟用“跳過”選項，并且會禁用儀表盤在UI中檢索和顯示它的功能。

該漏洞對Rancher 1.6.x和2.x意味著什么？

在Rancher 2.x中，默認情況下不會啟用Kubernetes儀表盤，因為Rancher 2.0用戶界面可用作替代方案。若您不會使用到儀表盤代碼庫，則不受此漏洞的影響。如果您更改了默認設(shè)置、在Rancher管理的任何Kubernetes集群之上部署了Kubernetes儀表盤，請務(wù)必使用Kubernetes官方提供的指南及補丁修復(fù)這一漏洞。

如果你使用的是Rancher 1.6.x，則完全無需擔(dān)心。在Rancher 1.6.x中，Kubernetes儀表盤作為每個Kubernetes集群環(huán)境的一部分包含在內(nèi)；但是，1.6.x部署不受影響，因為Rancher Server充當(dāng)了Kubernetes儀表盤的身份驗證授權(quán)和代理。它不利用默認的Kubernetes儀表盤登錄機制。此外，Rancher部署的Kubernetes儀表盤不使用任何自定義TLS證書。

Kubernetes API服務(wù)器外部IP地址代理漏洞

下面讓我們來探討Kubernetes公告所描述的第二個漏洞。

Kubernetes API服務(wù)器使用節(jié)點、node或服務(wù)代理API，將請求代理到pod或節(jié)點。通過直接修改podIP或nodeIP，可以將代理請求定向到任何IP。API服務(wù)器總是被部署在某網(wǎng)絡(luò)中的，利用這個漏洞就訪問該網(wǎng)絡(luò)中的任何可用IP了。盡管自從v1.10發(fā)布以來，Kubernetes已經(jīng)在很大程度上增加了檢查以緩解這個問題，但最近才發(fā)現(xiàn)有一條路徑的問題并沒有被完全解決——將代理指向本地地址到運行API服務(wù)器的主機。

該漏洞的運作原理

通過使用Kubernetes API，用戶可以使用節(jié)點代理、pod代理或服務(wù)代理API請求與pod或節(jié)點的連接。Kubernetes接受此請求，找到podIP或nodeIP的關(guān)聯(lián)IP，并最終將該請求轉(zhuǎn)發(fā)到該IP。這些通常由Kubernetes自動分配。但是，集群管理員（或具有類似“超級用戶”權(quán)限的不同角色）可以更新資源的podIP或nodeIP字段以指向任意IP。

這在很大程度上不是問題，因為“普通”用戶無法更改資源的podIP或nodeIP。podIP和nodeIP字段位于pod和節(jié)點資源的狀態(tài)子資源中。為了更新狀態(tài)子資源，必須專門授予RBAC規(guī)則。默認情況下，除了集群管理員和內(nèi)部Kubernetes組件（例如kubelet、controller-manager、scheduler）之外，沒有Kubernetes角色可以訪問狀態(tài)子資源。想要利用此漏洞，首先得擁有對集群的高級別訪問權(quán)限。

這一次Kubernetes官方發(fā)布的修復(fù)，是確定攻擊向量可以存在于與集群分開管理控制面板的設(shè)置中。在這種情況下，集群管理員是不能訪問運行API服務(wù)器的主機的。這種情況存在于您從云提供商處獲得的托管Kubernetes服務(wù)中。在這種情況下，集群管理員可以通過將podIP / nodeIP修改為本地地址（如127.0.0.1）來訪問API服務(wù)器的本地地址。今天發(fā)布的修復(fù)將阻止代理到本地地址。

這對Rancher用戶意味著什么？

Rancher托管集群的默認權(quán)限，僅允許集群所有者和成員更改podIP或nodeIP字段。將該權(quán)限提供給其他用戶時，必須假定允許用戶能夠完全訪問集群中的任何節(jié)點。所有其他默認角色（例如項目所有者/成員）都無權(quán)訪問這些字段。今天發(fā)布的修復(fù)程序所適用的部署的Kubernete集群，是其控制面板網(wǎng)絡(luò)與應(yīng)用程序使用的網(wǎng)絡(luò)不同的。在Rancher 1.6.x或2.x中創(chuàng)建的Kubernete集群，均默認集群管理員具有對控制面板節(jié)點的完全訪問權(quán)限。如果您正在使用Rancher 2.x，并且正在使用托管云提供商（例如EKS、GKE、AKS），請與他們核實安全性是否存在問題，因為控制面板是歸云提供商所有。

我們始終希望能確保Rancher用戶能夠在最短時間內(nèi)使用到最新的安全修復(fù)程序和相應(yīng)補丁，Kubernetes版本v1.10.12、v1.11.6和v1.12.4解決了這兩個安全漏洞，這三個版本的Kubernetes將可在Rancher 版本v2.1.5和v2.0.10中使用。如果你是Rancher v1.6.x版本的用戶，則無需做任何更新，因為標(biāo)準(zhǔn)的v1.6.x安裝不受這次安全漏洞影響。

您還可以通過下述兩個鏈接了解到Kubernetes官方針對這兩個漏洞的相應(yīng)討論：

https://discuss.kubernetes.io...