資訊專欄INFORMATION COLUMN
摘要：近期，儀表盤和外部代理接連被發(fā)現(xiàn)存在安全問題。本文將更深入解讀這兩個(gè)安全漏洞的原理會(huì)對(duì)您的部署造成的影響以及相應(yīng)的應(yīng)對(duì)之策。在中，儀表盤作為每個(gè)集群環(huán)境的一部分包含在內(nèi)但是，部署不受影響，因?yàn)槌洚?dāng)了儀表盤的身份驗(yàn)證授權(quán)和代理。
近期，Kubernetes儀表盤和外部IP代理接連被發(fā)現(xiàn)存在安全問題。針對(duì)這兩個(gè)漏洞，Kubernetes發(fā)布了相應(yīng)的補(bǔ)丁版本供會(huì)受漏洞影響的用戶解決問題。本文將更深入解讀這兩個(gè)安全漏洞的原理、會(huì)對(duì)您的Kubernetes部署造成的影響以及相應(yīng)的應(yīng)對(duì)之策。
通過kubernetes儀表盤訪問自定義TLS證書
Kubernetes儀表盤漏洞（CVE-2018-18264）會(huì)影響v1.10.0或更早的儀表盤版本。因?yàn)檫@一漏洞，用戶可以“跳過”登錄過程，假設(shè)配置的服務(wù)帳戶，最后獲得儀表盤所使用的自定義TLS證書。如果您已將Kubernetes儀表盤配置為需要登錄并將其配置為使用自定義TLS證書，那么這一漏洞會(huì)影響到您，您需要及時(shí)注意。
該漏洞的運(yùn)作原理
此漏洞可以分為兩部分來解釋。
第一個(gè)是，因?yàn)榈顷憰r(shí)用戶可以選擇“跳過”這一選項(xiàng)，那么任何用戶都可以繞過登錄過程，該過程在v1.10.0或更早版本中始終默認(rèn)啟用。這樣一來，用戶就完全跳過登錄過程并能使用儀表盤配置的服務(wù)帳戶。
第二個(gè)是，使用儀表盤配置的服務(wù)帳戶，必須最低限度地有權(quán)限訪問自定義TLS證書（以secret的形式存儲(chǔ)）。未經(jīng)身份驗(yàn)證的登錄，加上儀表板使用配置的服務(wù)帳戶來檢索這些secret的能力，組合在一起的結(jié)果就是這一安全問題。
使用儀表盤v1.10.1補(bǔ)丁時(shí)，默認(rèn)情況下將不再啟用“跳過”選項(xiàng)，并且會(huì)禁用儀表盤在UI中檢索和顯示它的功能。
該漏洞對(duì)Rancher 1.6.x和2.x意味著什么？
在Rancher 2.x中，默認(rèn)情況下不會(huì)啟用Kubernetes儀表盤，因?yàn)镽ancher 2.0用戶界面可用作替代方案。若您不會(huì)使用到儀表盤代碼庫(kù)，則不受此漏洞的影響。如果您更改了默認(rèn)設(shè)置、在Rancher管理的任何Kubernetes集群之上部署了Kubernetes儀表盤，請(qǐng)務(wù)必使用Kubernetes官方提供的指南及補(bǔ)丁修復(fù)這一漏洞。
如果你使用的是Rancher 1.6.x，則完全無需擔(dān)心。在Rancher 1.6.x中，Kubernetes儀表盤作為每個(gè)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公告所描述的第二個(gè)漏洞。
Kubernetes API服務(wù)器使用節(jié)點(diǎn)、node或服務(wù)代理API，將請(qǐng)求代理到pod或節(jié)點(diǎn)。通過直接修改podIP或nodeIP，可以將代理請(qǐng)求定向到任何IP。API服務(wù)器總是被部署在某網(wǎng)絡(luò)中的，利用這個(gè)漏洞就訪問該網(wǎng)絡(luò)中的任何可用IP了。盡管自從v1.10發(fā)布以來，Kubernetes已經(jīng)在很大程度上增加了檢查以緩解這個(gè)問題，但最近才發(fā)現(xiàn)有一條路徑的問題并沒有被完全解決——將代理指向本地地址到運(yùn)行API服務(wù)器的主機(jī)。
該漏洞的運(yùn)作原理
通過使用Kubernetes API，用戶可以使用節(jié)點(diǎn)代理、pod代理或服務(wù)代理API請(qǐng)求與pod或節(jié)點(diǎn)的連接。Kubernetes接受此請(qǐng)求，找到podIP或nodeIP的關(guān)聯(lián)IP，并最終將該請(qǐng)求轉(zhuǎn)發(fā)到該IP。這些通常由Kubernetes自動(dòng)分配。但是，集群管理員（或具有類似“超級(jí)用戶”權(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)子資源。想要利用此漏洞，首先得擁有對(duì)集群的高級(jí)別訪問權(quán)限。
這一次Kubernetes官方發(fā)布的修復(fù)，是確定攻擊向量可以存在于與集群分開管理控制面板的設(shè)置中。在這種情況下，集群管理員是不能訪問運(yùn)行API服務(wù)器的主機(jī)的。這種情況存在于您從云提供商處獲得的托管Kubernetes服務(wù)中。在這種情況下，集群管理員可以通過將podIP / nodeIP修改為本地地址（如127.0.0.1）來訪問API服務(wù)器的本地地址。今天發(fā)布的修復(fù)將阻止代理到本地地址。
這對(duì)Rancher用戶意味著什么？
Rancher托管集群的默認(rèn)權(quán)限，僅允許集群所有者和成員更改podIP或nodeIP字段。將該權(quán)限提供給其他用戶時(shí)，必須假定允許用戶能夠完全訪問集群中的任何節(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)集群管理員具有對(duì)控制面板節(jié)點(diǎn)的完全訪問權(quán)限。如果您正在使用Rancher 2.x，并且正在使用托管云提供商（例如EKS、GKE、AKS），請(qǐng)與他們核實(shí)安全性是否存在問題，因?yàn)榭刂泼姘迨菤w云提供商所有。
我們始終希望能確保Rancher用戶能夠在最短時(shí)間內(nèi)使用到最新的安全修復(fù)程序和相應(yīng)補(bǔ)丁，Kubernetes版本v1.10.12、v1.11.6和v1.12.4解決了這兩個(gè)安全漏洞，這三個(gè)版本的Kubernetes將可在Rancher 版本v2.1.5和v2.0.10中使用。如果你是Rancher v1.6.x版本的用戶，則無需做任何更新，因?yàn)闃?biāo)準(zhǔn)的v1.6.x安裝不受這次安全漏洞影響。
您還可以通過下述兩個(gè)鏈接了解到Kubernetes官方針對(duì)這兩個(gè)漏洞的相應(yīng)討論：
https://discuss.kubernetes.io...
https://discuss.kubernetes.io...
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/32829.html
摘要：爆出中等嚴(yán)重性安全漏洞拒絕服務(wù)漏洞。本文將進(jìn)行漏洞解讀和情景再現(xiàn)，并分享漏洞修復(fù)方案，用戶來看應(yīng)對(duì)之策了漏洞美國(guó)當(dāng)?shù)貢r(shí)間年月日，社區(qū)發(fā)布了拒絕服務(wù)的漏洞，即有寫入權(quán)限的用戶在寫入資源時(shí)會(huì)導(dǎo)致過度消耗資源，此漏洞被評(píng)級(jí)為中等嚴(yán)重性。 Kubernetes爆出中等嚴(yán)重性安全漏洞——Kubernetes API Server拒絕服務(wù)漏洞CVE-2019-1002100。 本文將進(jìn)行漏洞解讀和...
摘要：年月日，研究人員通過郵件列表披露了容器逃逸漏洞的詳情，根據(jù)的規(guī)定會(huì)在天后也就是年月日公開。在號(hào)當(dāng)天已通過公眾號(hào)文章詳細(xì)分析了漏洞詳情和用戶的應(yīng)對(duì)之策。 美國(guó)時(shí)間2019年2月11日晚，runc通過oss-security郵件列表披露了runc容器逃逸漏洞CVE-2019-5736的詳情。runc是Docker、CRI-O、Containerd、Kubernetes等底層的容器運(yùn)行時(shí)，此...
摘要：今天，發(fā)布了一系列補(bǔ)丁版本，修復(fù)新近發(fā)現(xiàn)的兩個(gè)安全漏洞命令安全漏洞和端口映射插件漏洞。因?yàn)槎丝谟成洳寮乔度氲桨姹局械?，只有升?jí)至新版本的才能解決此問題?，F(xiàn)在修復(fù)之后，將端口映射插件的規(guī)則由最優(yōu)先變?yōu)楦郊?，則可以讓流量?jī)?yōu)先由規(guī)則處理。 今天，Kubernetes發(fā)布了一系列補(bǔ)丁版本，修復(fù)新近發(fā)現(xiàn)的兩個(gè)安全漏洞CVE-2019-1002101（kubectl cp命令安全漏洞）和CVE-...
摘要：本文將介紹通過強(qiáng)身份驗(yàn)證如何確保企業(yè)的集群免受外部攻擊。服務(wù)器雖然面向公開，但是受到證書身份驗(yàn)證的保護(hù)。年年底被爆出的首個(gè)嚴(yán)重安全漏洞，就是由聯(lián)合創(chuàng)始人及首席架構(gòu)師發(fā)現(xiàn)的。 毋庸置疑，K8s已經(jīng)成為云容器編排系統(tǒng)的標(biāo)準(zhǔn)，但是，如果缺乏K8s環(huán)境相關(guān)的安全問題認(rèn)識(shí)的話，會(huì)致使各種組件暴露在網(wǎng)絡(luò)集群內(nèi)外的攻擊之下。本文將介紹通過強(qiáng)身份驗(yàn)證如何確保企業(yè)的K8s集群免受外部攻擊。 showIm...
摘要：漏洞披露后，在第一時(shí)間發(fā)布了，用戶可升級(jí)到此版本以修復(fù)該漏洞。年年底被爆出的首個(gè)嚴(yán)重安全漏洞，就是由聯(lián)合創(chuàng)始人及首席架構(gòu)師發(fā)現(xiàn)的。年月被爆出儀表盤和外部代理安全漏洞時(shí)，也是第一時(shí)間向用戶響應(yīng)，確保所有和的用戶都完全不被漏洞影響。 runC是一個(gè)根據(jù)OCI（Open Container Initiative）標(biāo)準(zhǔn)創(chuàng)建并運(yùn)行容器的CLI工具，目前Docker引擎內(nèi)部也是基于runc構(gòu)建的。...
閱讀 1584·2021-09-22 15:52
閱讀 3494·2021-09-22 14:59
閱讀 2925·2021-09-02 15:12
閱讀 1008·2021-08-20 09:35
閱讀 1602·2019-08-30 14:09
閱讀 2736·2019-08-30 13:56
閱讀 1687·2019-08-26 18:27
閱讀 3389·2019-08-26 13:37
