Kubernetes安全三步談：如何通過RBAC和強(qiáng)身份驗證確保外部安全

毋庸置疑，K8s已經(jīng)成為云容器編排系統(tǒng)的標(biāo)準(zhǔn)，但是，如果缺乏K8s環(huán)境相關(guān)的安全問題認(rèn)識的話，會致使各種組件暴露在網(wǎng)絡(luò)集群內(nèi)外的***之下。本文將介紹通過強(qiáng)身份驗證如何確保企業(yè)的K8s集群免受外部***。
 

 

這是關(guān)于Kubernetes安全性的三篇系列文章中的第一篇，在本系列文章中，我們將依次介紹如何確保企業(yè)的Kubernetes集群免受外部***、內(nèi)部***，以及如何處理資源消耗或noisy neighbors問題。

 
毋庸置疑，Kubernetes已經(jīng)成為云容器編排系統(tǒng)的標(biāo)準(zhǔn)，據(jù)Cloud Native Computing Foundation（CNCF）的定義，它提供了一個“自動化部署、擴(kuò)展以及跨主機(jī)集群操作應(yīng)用程序容器的平臺”。但是，如果缺乏Kubernetes環(huán)境相關(guān)的安全問題認(rèn)識的話，會致使各種組件暴露在網(wǎng)絡(luò)集群內(nèi)外的***之下。

鎖定API服務(wù)器，Kubelets

Kubernetes環(huán)境中有多種可由外部訪問的組件，包括應(yīng)用程序編程接口（API）服務(wù)器、kubelet以及數(shù)據(jù)存儲。如果沒有正確鎖定和保護(hù)它們的話，這些組件有可能會造成數(shù)據(jù)泄漏和系統(tǒng)損害。

 
Kubernetes為開發(fā)、運(yùn)維和安全團(tuán)隊提供了一個API結(jié)構(gòu)，可用于和應(yīng)用程序和Kubernetes平臺交互。Kubelet是一個在節(jié)點(diǎn)上運(yùn)行并且讀取容器清單的服務(wù)，它確保定義了的容器已經(jīng)啟動并運(yùn)行。Kubernetes利用etcd分布式鍵值存儲來保存和復(fù)制Kubernetes在整個集群中使用的數(shù)據(jù)?；旧希罱?jīng)常受到***的Kubernetes系統(tǒng)是那些根本沒有設(shè)置訪問控制的系統(tǒng)。

Goins指出，Kubernetes易于部署，在默認(rèn)情況下并沒有內(nèi)置太多確保安全性的東西。例如，直到2017年年中，容器編排系統(tǒng)才開始具有RBAC（基于角色的訪問控制）功能。

Kubernetes 1.8版本的亮點(diǎn)之一是RBAC（基于角色的訪問控制），這是一種用于管理Kubernetes資源周圍權(quán)限的授權(quán)機(jī)制。RBAC允許配置靈活的授權(quán)策略，可以在不需要重啟集群的情況下進(jìn)行更新。

“在很多Kubernetes部署中，一旦出現(xiàn)compromise，用戶可以使用root權(quán)限安裝和運(yùn)行他們想要的軟件。”Goins說，“***和網(wǎng)絡(luò)犯罪分子希望進(jìn)入一個系統(tǒng)，升級他們的權(quán)限，接著轉(zhuǎn)向其他系統(tǒng)，開始收集信用卡和個人身份識別數(shù)據(jù)等信息。”

2018年12月在Kubernetes爆出的首個安全漏洞——特權(quán)升級漏洞(CVE-2018-1002105)，當(dāng)時是由Rancher Labs聯(lián)合創(chuàng)始人及首席架構(gòu)師Darren Shepherd發(fā)現(xiàn)的。該漏洞演示了用戶如何通過Kubernetes API服務(wù)器建立和后端服務(wù)器的連接。建立連接之后，***者可以通過網(wǎng)絡(luò)連接直接向后端集群服務(wù)（如kubelets）發(fā)送任意的請求。該漏洞讓任何用戶在任何計算節(jié)點(diǎn)上都擁有完整的管理員權(quán)限。后來發(fā)布了專門修復(fù)受支持的Kubernetes版本的補(bǔ)丁，在1.10.11，1.11.5和1.12.3中都提供了這樣的補(bǔ)丁。
 

企業(yè)該如何保護(hù)K8s集群免受外部***

Goins建議，Kubernetes用戶需要做的第一件事是完全關(guān)閉外部API訪問，或者將該功能封裝在某種強(qiáng)身份驗證中設(shè)置保護(hù)。為了減輕外部***的威脅，信息技術(shù)/安全管理員必須確保只有必要的Kubernetes服務(wù)能對外暴露。此外，他們必須設(shè)置身份驗證并且給所有公開的服務(wù)配置正確的網(wǎng)絡(luò)安全策略。

Handy Tecchnologies的Alexander Uricoli在一篇博客中寫道：“除非你在kubelet上指定了一些標(biāo)志（flags），否則它在默認(rèn)操作模式下，是會接受未經(jīng)身份驗證的API請求的?！痹谶@篇博客中Uricoli分析了***是如何***同時個人服務(wù)器上的Kubernetes集群的：

https://medium.com/handy-tech/analysis-of-a-kubernetes-hack-backdooring-through-kubelet-823be5c3d67c

Uricoli說：“看來有人找到了一種方法，可以在一個正在運(yùn)行的容器上放置一些加密挖掘軟件，然后執(zhí)行這個過程?！盞ubernetes API服務(wù)器雖然面向internet公開，但是受到證書身份驗證的保護(hù)。

 
結(jié)果，同事的服務(wù)器公開了kubelet端口（tcp 10250和tcp 10255）。Uricoli指出，盡管問題已顯而易見，這樣的***仍然應(yīng)該引起大家對Kubernetes的部署的一些問題的關(guān)注。如果你的用戶可以通過網(wǎng)絡(luò)節(jié)點(diǎn)來訪問你的節(jié)點(diǎn)，那么kubelet API就是一個通往集群的API后門，它功能齊全且未經(jīng)身份驗證。如果用戶已經(jīng)花了很多心思在webhook、RBAC或其他方法啟用身份驗證和授權(quán)上，那么他們也同樣應(yīng)該將kubelet好好地鎖定上。

 
互聯(lián)網(wǎng)安全中心（CIS）建議用戶為kubelet連接部署HTTPS。CIS在關(guān)于為Kubernetes 1.11建立安全配置的指南中寫道，“從API服務(wù)器到kubelets的連接可能帶有機(jī)密和密鑰等敏感數(shù)據(jù)。因此，在API服務(wù)器和kubeletes之間的任何通信中使用在途加密（in-transit）是非常重要的?！?br/> 

 
Kubernetes用戶應(yīng)該禁用對API服務(wù)器的匿名請求。啟用時，沒有被其他配置好的身份驗證方法拒絕的請求將被視為匿名請求，然后API服務(wù)器會處理這些請求。根據(jù)CIS的說法，Kubernetes的用戶應(yīng)該依靠身份驗證來授權(quán)訪問，并切拒絕匿名請求，而組織應(yīng)該根據(jù)需要實(shí)現(xiàn)可控制的訪問。
 

Goins指出，加強(qiáng)內(nèi)部集群用戶防御的安全控制——RBAC、隔離以及權(quán)限限制——對于保護(hù)Kubernetes免受外部***同等重要。

他說：“如果有人使用任何內(nèi)部用戶的賬戶從外部訪問集群，他們會立刻獲得完全訪問權(quán)限。”所以，這并不是說你需要內(nèi)部控制來抵御外部的***。而是說如果你沒有這些措施，當(dāng)受到***的時候你就遭大殃了。

結(jié) 語

Rancher Kubernetes平臺擁有著超過一億次下載量，我們深知安全問題對于用戶而言的重要性，更遑論那些通過Rancher平臺在生產(chǎn)環(huán)境中運(yùn)行Docker及Kubernetes的數(shù)千萬用戶。

2018年年底Kubernetes被爆出的首個嚴(yán)重安全漏洞CVE-2018-1002105，就是由Rancher Labs聯(lián)合創(chuàng)始人及首席架構(gòu)師Darren Shepherd發(fā)現(xiàn)的。

2019年1月Kubernetes被爆出儀表盤和外部IP代理安全漏洞時，Rancher Labs也是業(yè)界第一時間向用戶響應(yīng)，確保了所有Rancher 2.x和1.6.x的用戶都完全不被漏洞影響。

未來Rancher將會向用戶分享更多容器及Kubernetes安全技巧。在下一篇博客中，我們將分享三種保護(hù)Kubernetes不受內(nèi)部***的方法：基于角色的訪問、Kubernetes特性（如邏輯隔離，即命名空間）和Rancher資源（如Project）。記得保持關(guān)注~