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

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

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

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

該漏洞的運(yùn)作原理

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

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

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

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

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

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

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

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

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

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

 
該漏洞的運(yùn)作原理

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

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

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

這對Rancher用戶意味著什么？

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

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

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

https://discuss.kubernetes.io/t/security-release-of-dashboard-v1-10-1-cve-2018-18264/4069
 

https://discuss.kubernetes.io/t/security-impact-of-kubernetes-api-server-external-ip-address-proxying/4072