云計算
毋庸置疑，K8s已經(jīng)成為云容器編排系統(tǒng)的標準，但是，如果缺乏K8s環(huán)境相關的安全問題認識的話，會致使各種組件暴露在網(wǎng)絡集群內(nèi)外的***之下。本文將介紹通過強身份驗證如何確保企業(yè)的K8s集群免受外部***。
這是關于Kubernetes安全性的三篇系列文章中的第一篇，在本系列文章中，我們將依次介紹如何確保企業(yè)的Kubernetes集群免受外部***、內(nèi)部***，以及如何處理資源消耗或noisy neighbors問題。
毋庸置疑，Kubernetes已經(jīng)成為云容器編排系統(tǒng)的標準，據(jù)Cloud Native Computing Foundation（CNCF）的定義，它提供了一個“自動化部署、擴展以及跨主機集群操作應用程序容器的平臺”。但是，如果缺乏Kubernetes環(huán)境相關的安全問題認識的話，會致使各種組件暴露在網(wǎng)絡集群內(nèi)外的***之下。
鎖定API服務器，Kubelets
Kubernetes環(huán)境中有多種可由外部訪問的組件，包括應用程序編程接口（API）服務器、kubelet以及數(shù)據(jù)存儲。如果沒有正確鎖定和保護它們的話，這些組件有可能會造成數(shù)據(jù)泄漏和系統(tǒng)損害。
Kubernetes為開發(fā)、運維和安全團隊提供了一個API結(jié)構(gòu)，可用于和應用程序和Kubernetes平臺交互。Kubelet是一個在節(jié)點上運行并且讀取容器清單的服務，它確保定義了的容器已經(jīng)啟動并運行。Kubernetes利用etcd分布式鍵值存儲來保存和復制Kubernetes在整個集群中使用的數(shù)據(jù)。基本上，最經(jīng)常受到***的Kubernetes系統(tǒng)是那些根本沒有設置訪問控制的系統(tǒng)。
Goins指出，Kubernetes易于部署，在默認情況下并沒有內(nèi)置太多確保安全性的東西。例如，直到2017年年中，容器編排系統(tǒng)才開始具有RBAC（基于角色的訪問控制）功能。
Kubernetes 1.8版本的亮點之一是RBAC（基于角色的訪問控制），這是一種用于管理Kubernetes資源周圍權(quán)限的授權(quán)機制。RBAC允許配置靈活的授權(quán)策略，可以在不需要重啟集群的情況下進行更新。
“在很多Kubernetes部署中，一旦出現(xiàn)compromise，用戶可以使用root權(quán)限安裝和運行他們想要的軟件?！盙oins說，“***和網(wǎng)絡犯罪分子希望進入一個系統(tǒng)，升級他們的權(quán)限，接著轉(zhuǎn)向其他系統(tǒng)，開始收集信用卡和個人身份識別數(shù)據(jù)等信息?！?/p>
2018年12月在Kubernetes爆出的首個安全漏洞——特權(quán)升級漏洞(CVE-2018-1002105)，當時是由Rancher Labs聯(lián)合創(chuàng)始人及首席架構(gòu)師Darren Shepherd發(fā)現(xiàn)的。該漏洞演示了用戶如何通過Kubernetes API服務器建立和后端服務器的連接。建立連接之后，***者可以通過網(wǎng)絡連接直接向后端集群服務（如kubelets）發(fā)送任意的請求。該漏洞讓任何用戶在任何計算節(jié)點上都擁有完整的管理員權(quán)限。后來發(fā)布了專門修復受支持的Kubernetes版本的補丁，在1.10.11，1.11.5和1.12.3中都提供了這樣的補丁。
企業(yè)該如何保護K8s集群免受外部***
Goins建議，Kubernetes用戶需要做的第一件事是完全關閉外部API訪問，或者將該功能封裝在某種強身份驗證中設置保護。為了減輕外部***的威脅，信息技術(shù)/安全管理員必須確保只有必要的Kubernetes服務能對外暴露。此外，他們必須設置身份驗證并且給所有公開的服務配置正確的網(wǎng)絡安全策略。
Handy Tecchnologies的Alexander Uricoli在一篇博客中寫道：“除非你在kubelet上指定了一些標志（flags），否則它在默認操作模式下，是會接受未經(jīng)身份驗證的API請求的?！痹谶@篇博客中Uricoli分析了***是如何***同時個人服務器上的Kubernetes集群的：
https://medium.com/handy-tech/analysis-of-a-kubernetes-hack-backdooring-through-kubelet-823be5c3d67c
Uricoli說：“看來有人找到了一種方法，可以在一個正在運行的容器上放置一些加密挖掘軟件，然后執(zhí)行這個過程?！盞ubernetes API服務器雖然面向internet公開，但是受到證書身份驗證的保護。
結(jié)果，同事的服務器公開了kubelet端口（tcp 10250和tcp 10255）。Uricoli指出，盡管問題已顯而易見，這樣的***仍然應該引起大家對Kubernetes的部署的一些問題的關注。如果你的用戶可以通過網(wǎng)絡節(jié)點來訪問你的節(jié)點，那么kubelet API就是一個通往集群的API后門，它功能齊全且未經(jīng)身份驗證。如果用戶已經(jīng)花了很多心思在webhook、RBAC或其他方法啟用身份驗證和授權(quán)上，那么他們也同樣應該將kubelet好好地鎖定上。
互聯(lián)網(wǎng)安全中心（CIS）建議用戶為kubelet連接部署HTTPS。CIS在關于為Kubernetes 1.11建立安全配置的指南中寫道，“從API服務器到kubelets的連接可能帶有機密和密鑰等敏感數(shù)據(jù)。因此，在API服務器和kubeletes之間的任何通信中使用在途加密（in-transit）是非常重要的?！?br/>
Kubernetes用戶應該禁用對API服務器的匿名請求。啟用時，沒有被其他配置好的身份驗證方法拒絕的請求將被視為匿名請求，然后API服務器會處理這些請求。根據(jù)CIS的說法，Kubernetes的用戶應該依靠身份驗證來授權(quán)訪問，并切拒絕匿名請求，而組織應該根據(jù)需要實現(xiàn)可控制的訪問。
Goins指出，加強內(nèi)部集群用戶防御的安全控制——RBAC、隔離以及權(quán)限限制——對于保護Kubernetes免受外部***同等重要。
他說：“如果有人使用任何內(nèi)部用戶的賬戶從外部訪問集群，他們會立刻獲得完全訪問權(quán)限?！彼?，這并不是說你需要內(nèi)部控制來抵御外部的***。而是說如果你沒有這些措施，當受到***的時候你就遭大殃了。
結(jié) 語
Rancher Kubernetes平臺擁有著超過一億次下載量，我們深知安全問題對于用戶而言的重要性，更遑論那些通過Rancher平臺在生產(chǎn)環(huán)境中運行Docker及Kubernetes的數(shù)千萬用戶。
2018年年底Kubernetes被爆出的首個嚴重安全漏洞CVE-2018-1002105，就是由Rancher Labs聯(lián)合創(chuàng)始人及首席架構(gòu)師Darren Shepherd發(fā)現(xiàn)的。
2019年1月Kubernetes被爆出儀表盤和外部IP代理安全漏洞時，Rancher Labs也是業(yè)界第一時間向用戶響應，確保了所有Rancher 2.x和1.6.x的用戶都完全不被漏洞影響。
未來Rancher將會向用戶分享更多容器及Kubernetes安全技巧。在下一篇博客中，我們將分享三種保護Kubernetes不受內(nèi)部***的方法：基于角色的訪問、Kubernetes特性（如邏輯隔離，即命名空間）和Rancher資源（如Project）。記得保持關注~
重慶分公司
重慶分公司
