Kubernetes安全三步談：如何經過RBAC和強身份驗證確保外部安全

毋庸置疑，K8s已經成爲雲容器編排系統的標準，可是，若是缺少K8s環境相關的安全問題認識的話，會導致各類組件暴露在網絡集羣內外的攻擊之下。本文將介紹經過強身份驗證如何確保企業的K8s集羣免受外部攻擊。

---

這是關於Kubernetes安全性的三篇系列文章中的第一篇，在本系列文章中，咱們將依次介紹如何確保企業的Kubernetes集羣免受外部攻擊、內部攻擊，以及如何處理資源消耗或noisy neighbors問題。

毋庸置疑，Kubernetes已經成爲雲容器編排系統的標準，據Cloud Native Computing Foundation（CNCF）的定義，它提供了一個「自動化部署、擴展以及跨主機集羣操做應用程序容器的平臺」。可是，若是缺少Kubernetes環境相關的安全問題認識的話，會導致各類組件暴露在網絡集羣內外的攻擊之下。

鎖定API服務器，Kubelets

Kubernetes環境中有多種可由外部訪問的組件，包括應用程序編程接口（API）服務器、kubelet以及數據存儲。若是沒有正確鎖定和保護它們的話，這些組件有可能會形成數據泄漏和系統損害。

Kubernetes爲開發、運維和安全團隊提供了一個API結構，可用於和應用程序和Kubernetes平臺交互。Kubelet是一個在節點上運行而且讀取容器清單的服務，它確保定義了的容器已經啓動並運行。Kubernetes利用etcd分佈式鍵值存儲來保存和複製Kubernetes在整個集羣中使用的數據。基本上，最常常受到攻擊的Kubernetes系統是那些根本沒有設置訪問控制的系統。

Goins指出，Kubernetes易於部署，在默認狀況下並無內置太多確保安全性的東西。例如，直到2017年年中，容器編排系統纔開始具備RBAC（基於角色的訪問控制）功能。

Kubernetes 1.8版本的亮點之一是RBAC（基於角色的訪問控制），這是一種用於管理Kubernetes資源周圍權限的受權機制。RBAC容許配置靈活的受權策略，能夠在不須要重啓集羣的狀況下進行更新。

「在不少Kubernetes部署中，一旦出現compromise，用戶可使用root權限安裝和運行他們想要的軟件。」Goins說，「黑客和網絡犯罪分子但願進入一個系統，升級他們的權限，接着轉向其餘系統，開始收集信用卡和我的身份識別數據等信息。」

2018年12月在Kubernetes爆出的首個安全漏洞——特權升級漏洞(CVE-2018-1002105)，當時是由Rancher Labs聯合創始人及首席架構師Darren Shepherd發現的。該漏洞演示了用戶如何經過Kubernetes API服務器創建和後端服務器的鏈接。創建鏈接以後，攻擊者能夠經過網絡鏈接直接向後端集羣服務（如kubelets）發送任意的請求。該漏洞讓任何用戶在任何計算節點上都擁有完整的管理員權限。後來發佈了專門修復受支持的Kubernetes版本的補丁，在1.10.11，1.11.5和1.12.3中都提供了這樣的補丁。

企業該如何保護K8s集羣免受外部攻擊

Goins建議，Kubernetes用戶須要作的第一件事是徹底關閉外部API訪問，或者將該功能封裝在某種強身份驗證中設置保護。爲了減輕外部攻擊的威脅，信息技術/安全管理員必須確保只有必要的Kubernetes服務能對外暴露。此外，他們必須設置身份驗證而且給全部公開的服務配置正確的網絡安全策略。

Handy Tecchnologies的Alexander Uricoli在一篇博客中寫道：「除非你在kubelet上指定了一些標誌（flags），不然它在默認操做模式下，是會接受未經身份驗證的API請求的。」在這篇博客中Uricoli分析了黑客是如何入侵同時我的服務器上的Kubernetes集羣的：

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

Uricoli說：「看來有人找到了一種方法，能夠在一個正在運行的容器上放置一些加密挖掘軟件，而後執行這個過程。」Kubernetes API服務器雖然面向internet公開，可是受到證書身份驗證的保護。

結果，同事的服務器公開了kubelet端口（tcp 10250和tcp 10255）。Uricoli指出，儘管問題已顯而易見，這樣的入侵仍然應該引發你們對Kubernetes的部署的一些問題的關注。若是你的用戶能夠經過網絡節點來訪問你的節點，那麼kubelet API就是一個通往集羣的API後門，它功能齊全且未經身份驗證。若是用戶已經花了不少心思在webhook、RBAC或其餘方法啓用身份驗證和受權上，那麼他們也一樣應該將kubelet好好地鎖定上。

互聯網安全中心（CIS）建議用戶爲kubelet鏈接部署HTTPS。CIS在關於爲Kubernetes 1.11創建安全配置的指南中寫道，「從API服務器到kubelets的鏈接可能帶有機密和密鑰等敏感數據。所以，在API服務器和kubeletes之間的任何通訊中使用在途加密（in-transit）是很是重要的。」

Kubernetes用戶應該禁用對API服務器的匿名請求。啓用時，沒有被其餘配置好的身份驗證方法拒絕的請求將被視爲匿名請求，而後API服務器會處理這些請求。根據CIS的說法，Kubernetes的用戶應該依靠身份驗證來受權訪問，並切拒絕匿名請求，而組織應該根據須要實現可控制的訪問。

Goins指出，增強內部集羣用戶防護的安全控制——RBAC、隔離以及權限限制——對於保護Kubernetes免受外部攻擊同等重要。

他說：「若是有人使用任何內部用戶的帳戶從外部訪問集羣，他們會馬上得到徹底訪問權限。」因此，這並非說你須要內部控制來抵禦外部的攻擊。而是說若是你沒有這些措施，當受到攻擊的時候你就遭大殃了。

結 語

Rancher Kubernetes平臺擁有着超過一億次下載量，咱們深知安全問題對於用戶而言的重要性，更遑論那些經過Rancher平臺在生產環境中運行Docker及Kubernetes的數千萬用戶。

2018年年末Kubernetes被爆出的首個嚴重安全漏洞CVE-2018-1002105，就是由Rancher Labs聯合創始人及首席架構師Darren Shepherd發現的。

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

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