容器云平臺(tái)的安全性設(shè)計(jì)

1、容器云平臺(tái)的安全性設(shè)計(jì)目錄 HYPERLINK l _TOC_250011 容器云平臺(tái)概述01 HYPERLINK l _TOC_250010 容器云平臺(tái)風(fēng)險(xiǎn)及挑戰(zhàn)舉例01 HYPERLINK l _TOC_250009 軟件漏洞風(fēng)險(xiǎn).01 HYPERLINK l _TOC_250008 API安全風(fēng)險(xiǎn).02 HYPERLINK l _TOC_250007 鏡像安全風(fēng)險(xiǎn).02 HYPERLINK l _TOC_250006 網(wǎng)絡(luò)安全風(fēng)險(xiǎn).03 HYPERLINK l _TOC_250005 容器云平臺(tái)安全設(shè)計(jì)03 HYPERLINK l _TOC_250004 基礎(chǔ)安全設(shè)計(jì).04 HYPERL

2、INK l _TOC_250003 管理安全設(shè)計(jì).08 HYPERLINK l _TOC_250002 應(yīng)用安全.16 HYPERLINK l _TOC_250001 容器云平臺(tái)建設(shè)指引21 HYPERLINK l _TOC_250000 參考資料21 PAGE 211 容器云平臺(tái)概述近年來(lái)，云計(jì)算的模式逐漸被業(yè)界認(rèn)可和接受。在國(guó)內(nèi)，包括政府、金融、運(yùn)營(yíng)商、能源等眾多行業(yè)以及中小企業(yè)，均將其業(yè)務(wù)進(jìn)行不同程度的云化。PaaS平臺(tái)服務(wù)作為云計(jì)算三大服務(wù)之一，是近幾年市場(chǎng)份額同比增長(zhǎng)最快的云計(jì)算服務(wù)。近年興起的容器技術(shù)憑借其彈性敏捷的特性和活躍強(qiáng)大的社區(qū)支持成為了推動(dòng)PaaS發(fā)展的核心技術(shù)?；谌萜?/p>

3、技術(shù)構(gòu)建的PaaS平臺(tái)也稱(chēng)為容器云平臺(tái)。容器技術(shù)在操作系統(tǒng)層面實(shí)現(xiàn)了對(duì)計(jì)算機(jī)系統(tǒng)資源的虛擬化，在操作系統(tǒng)中，通過(guò)對(duì) CPU、內(nèi)存和文件系統(tǒng)等資源的隔離、劃分和控制，實(shí)現(xiàn)進(jìn)程之間透明的資源使用。容器云平臺(tái)是通過(guò)容器編排引擎及容器運(yùn)行時(shí)等技術(shù)提供應(yīng)用運(yùn)行平臺(tái)，從而實(shí)現(xiàn)運(yùn)維自動(dòng)化、快速部署應(yīng)用、彈性伸縮和動(dòng)態(tài)調(diào)整應(yīng)用環(huán)境資源，進(jìn)而提高研發(fā)運(yùn)營(yíng)的效率，目前市場(chǎng)上主流的容器云平臺(tái)是基于Google Kubernetes（簡(jiǎn)稱(chēng)k8s）容器編排引擎和容器引擎建立。本文中介紹內(nèi)容也是針對(duì)此類(lèi)的容器云平臺(tái)。說(shuō) 明 1容器云平臺(tái)本身的單點(diǎn)故障是一大安全隱患，但本文不涉及如何設(shè)計(jì)一個(gè)高可用的容器云平臺(tái)，此部分將在高

4、可用章節(jié)介紹。Redhat OpenShift方案是RedHat的企業(yè)級(jí)增強(qiáng)發(fā)行版本，是一個(gè)很好的部署版本，核心原理和開(kāi)源版本相同，但本文不刻意針對(duì)OpenShift發(fā)行版本進(jìn)行介紹。2 容器云平臺(tái)風(fēng)險(xiǎn)及挑戰(zhàn)舉例作為平臺(tái)級(jí)的容器環(huán)境，比以往任何的基礎(chǔ)架構(gòu)平臺(tái)更加的接近業(yè)務(wù)，同時(shí)也包含了更多的層級(jí)和組件，因此也帶來(lái)了更多的風(fēng)險(xiǎn)；目前容器安全也是一個(gè)信息安全的新興領(lǐng)域，該領(lǐng)域的技術(shù)和產(chǎn)品也在不斷完善中，下面我們先從風(fēng)險(xiǎn)的角度列舉幾個(gè)常見(jiàn)的例子，讓大家對(duì)容器平臺(tái)安全有個(gè)感性認(rèn)識(shí)：軟件漏洞風(fēng)險(xiǎn)容器的設(shè)計(jì)雖然實(shí)現(xiàn)了良好的操作系統(tǒng)級(jí)隔離，但同時(shí)也存在很多安全隱患，比如容器是運(yùn)行在宿主機(jī)上的一種特殊的進(jìn)程，

5、那么多個(gè)容器之間使用的就還是同一個(gè)宿主機(jī)的操作系統(tǒng)內(nèi)核，其次在Linux內(nèi)核中，有很多資源和對(duì)象是不能被Namespace化的，最典型的例子是：時(shí)間，即如果某個(gè)容器修改了時(shí)間， 那整個(gè)宿主機(jī)的時(shí)間都會(huì)隨之修改，非計(jì)劃內(nèi)的修改系統(tǒng)時(shí)間，對(duì)于時(shí)間敏感的應(yīng)用可能引起數(shù)據(jù)錯(cuò)誤甚至進(jìn)程crash，老版本Oracle數(shù)據(jù)庫(kù)就存在這樣的問(wèn)題。Kubernetes作為容器編排引擎，如果在規(guī)劃和部署架構(gòu)方面存在缺陷，同樣會(huì)和傳統(tǒng)環(huán)境一樣容易受到外部攻擊者和具有惡意的內(nèi)部人員的攻擊。因此，需要保障大型容器云環(huán)境具有正確的安全部署體系結(jié)構(gòu)， 并為應(yīng)用上云提供安全最佳實(shí)踐。根據(jù)國(guó)家信息安全漏洞庫(kù)的統(tǒng)計(jì)，截止2019年

6、1月2日，Docker相關(guān)的漏洞共40個(gè)，其中包括Apache、RedHat、hyper、boot2docker、Jenkins等廠(chǎng)商產(chǎn)品或開(kāi)源項(xiàng)目。2018年，Kubernetes生態(tài)系統(tǒng)因發(fā)現(xiàn)Kubernetes的第一個(gè)主要安全漏洞（Kubernetes特權(quán)升級(jí)漏洞CVE-2018-1002105）而動(dòng)搖。該漏洞使攻擊者能夠通過(guò)k8s api server實(shí)現(xiàn)提升k8s普通用戶(hù)到k8s api- server的最高權(quán)限，然后運(yùn)行代碼來(lái)安裝惡意軟件，進(jìn)而破壞k8s集群。除此之外還有CVE-2019-11245 Kubernetes kubelet v1.13.6 and v1.14.2提權(quán)漏

7、洞，實(shí)現(xiàn)了在通常情況下以容器Dockerle中指定的USER運(yùn)行的容器，有時(shí)可以以root身份運(yùn)行（在容器重啟時(shí)，或者如果鏡像先前被拉到節(jié)點(diǎn)）。這種情況的出現(xiàn)違反了容器禁止以root（容器內(nèi)進(jìn)程運(yùn)行用戶(hù)是root）運(yùn)行的最佳實(shí)踐。API安全風(fēng)險(xiǎn)此部分集中關(guān)注容器云平臺(tái)基礎(chǔ)組件提供的api服務(wù)的安全問(wèn)題，比如k8s api server，如果在構(gòu)建容器云平臺(tái)時(shí)擴(kuò)展或者封裝了平臺(tái)管理api，也需要關(guān)注并進(jìn)行加固。Docker很多服務(wù)默認(rèn)監(jiān)聽(tīng)在Unix Socket上，比如unix:/var/run/docker.sock，為了實(shí)現(xiàn)集群管理， 還提供了一個(gè)遠(yuǎn)程管理接口的REST API，允許通過(guò)TC

8、P遠(yuǎn)程訪(fǎng)問(wèn)服務(wù)。開(kāi)啟沒(méi)有任何加密和訪(fǎng)問(wèn)控制的Docker Remote API服務(wù)是非常危險(xiǎn)的。尤其是將默認(rèn)的2375端口暴露到互聯(lián)網(wǎng)中，一旦被攻擊者發(fā)現(xiàn)， 攻擊者無(wú)需認(rèn)證即可訪(fǎng)問(wèn)到容器數(shù)據(jù)，從而導(dǎo)致敏感信息泄露，也可以惡意刪除容器上的數(shù)據(jù)，或可進(jìn)一步利用容器自身特性，直接訪(fǎng)問(wèn)主機(jī)上的敏感信息，獲取服務(wù)器root權(quán)限，對(duì)敏感文件進(jìn)行修改并最終完全控制服務(wù)器。在容器編排引擎kubernetes通過(guò)api server服務(wù)提供以下能力： 1提供了容器平臺(tái)管理的REST API接口；2提供其他模塊之間的數(shù)據(jù)交互和通信的樞紐;3資源配額控制的入口；4應(yīng)用部署的接口；通俗來(lái)講，api server就是整

9、個(gè)容器平臺(tái)的入口，任何用戶(hù)和程序?qū)嘿Y源的增刪改查操作都可以通過(guò)api server實(shí)現(xiàn)。因此，為了保證集群的安全，API-server需要提供完備的安全機(jī)制。鏡像安全風(fēng)險(xiǎn)開(kāi)發(fā)者通常會(huì)在公共倉(cāng)庫(kù)下載鏡像，這些鏡像一部分來(lái)源于開(kāi)發(fā)鏡像相應(yīng)軟件的官方廠(chǎng)商，但還有大量鏡像來(lái)自第三方組織甚至個(gè)人。比如一些自由軟件，由于開(kāi)源和自由獲取等特性在大量使用，同時(shí)由于沒(méi)有固定商業(yè)組織進(jìn)行支持，此類(lèi)軟件的鏡像多數(shù)是社區(qū)維護(hù)，鏡像的質(zhì)量參差不齊，更有甚者，可能鏡像就是不懷好意的黑客制作，如果一旦此類(lèi)鏡像在生產(chǎn)環(huán)境使用，勢(shì)必造成安全隱患。此外，在整個(gè)應(yīng)用開(kāi)發(fā)生命周期中，開(kāi)發(fā)人員、測(cè)試人員和運(yùn)維人員都有可能根據(jù)不同需

10、求下載并運(yùn)行第三方鏡像，所以在容器運(yùn)行前進(jìn)行鏡像檢查非常重要。網(wǎng)絡(luò)安全風(fēng)險(xiǎn)企業(yè)內(nèi)部容器云平臺(tái)一般在邊界上有很強(qiáng)的安全保障措施，但是在容器云平臺(tái)內(nèi)部，基于默認(rèn)的網(wǎng)絡(luò)模型，比如annel，各個(gè)容器pod節(jié)點(diǎn)是扁平的，在橫向網(wǎng)絡(luò)訪(fǎng)問(wèn)隔離方面缺少必要的安全保障，基于annel 方案在容器云平臺(tái)構(gòu)建實(shí)踐中是較普遍采用的網(wǎng)絡(luò)模型，優(yōu)勢(shì)是成熟，簡(jiǎn)單，但卻缺乏訪(fǎng)問(wèn)控制。企業(yè)內(nèi)部容器云平臺(tái)一般在邊界上有很強(qiáng)的安全保障措施，但是在容器云平臺(tái)內(nèi)部，基于默認(rèn)的網(wǎng)絡(luò)模型，比如annel，各個(gè)容器pod節(jié)點(diǎn)是扁平的，在橫向網(wǎng)絡(luò)訪(fǎng)問(wèn)隔離方面缺少必要的安全保障，基于annel 方案在容器云平臺(tái)構(gòu)建實(shí)踐中是較普遍采用的網(wǎng)絡(luò)模型

11、，優(yōu)勢(shì)是成熟，簡(jiǎn)單，但卻缺乏訪(fǎng)問(wèn)控制。企業(yè)需要在構(gòu)建容器云平臺(tái)時(shí)考慮如何增強(qiáng)網(wǎng)絡(luò)訪(fǎng)問(wèn)控制，進(jìn)而提升網(wǎng)絡(luò)安全。3 容器云平臺(tái)安全設(shè)計(jì)容器云平臺(tái)架構(gòu)典型容器云平臺(tái)，參照上面平臺(tái)架構(gòu)設(shè)計(jì)，包括如下幾部分，從下到上包括分別是：基礎(chǔ)設(shè)施，容器云平臺(tái)基礎(chǔ)組件部分， 容器云管理平臺(tái)部分，業(yè)務(wù)應(yīng)用部分平臺(tái)支持系統(tǒng)部分。其中，基礎(chǔ)設(shè)施部分是容器云平臺(tái)的基石，提供了容器云平臺(tái)的運(yùn)行基礎(chǔ)計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)資源。此部分和原來(lái)傳統(tǒng)數(shù)據(jù)中心運(yùn)行的情況一致，安全要求也沒(méi)有明顯變化，因此相關(guān)安全設(shè)計(jì)要求參照原來(lái)數(shù)據(jù)中心設(shè)計(jì)規(guī)范進(jìn)行設(shè)計(jì)以及實(shí)現(xiàn)，不作為容器云平安全設(shè)計(jì)的重點(diǎn)；容器云平臺(tái)基礎(chǔ)組件部分提供容器云基礎(chǔ)功能，主要包括容器

12、運(yùn)行時(shí)實(shí)現(xiàn)和編排引擎，其中運(yùn)行部分包括虛擬化，軟件定義網(wǎng)絡(luò)，軟件定義存儲(chǔ)，編排引擎主要是kubernetes軟件；容器云管理平臺(tái)部分主要實(shí)現(xiàn)了容器平臺(tái)的核心功能，比如容器調(diào)度功能， 賬戶(hù)功能（也稱(chēng)租戶(hù)功能），鏡像管理功能，持續(xù)集成持續(xù)交付部分，此外還包括圖形化和命令行管理接口以及方便第三方對(duì)接的平臺(tái)API接口。容器平臺(tái)基礎(chǔ)組件部分和容器云管理平臺(tái)部分是容器云平臺(tái)安全設(shè)計(jì) 的關(guān)鍵；業(yè)務(wù)應(yīng)用部分，主要是容器平臺(tái)上部署的業(yè)務(wù)應(yīng)用，有些容器云平臺(tái)也提供了應(yīng)用市場(chǎng)功能。根據(jù)云平臺(tái)責(zé)任分擔(dān)模型，此部分安全是業(yè)務(wù)功能實(shí)現(xiàn)方提供，云平臺(tái)給出一定的安全最佳實(shí)踐指導(dǎo)。平臺(tái)支持系統(tǒng)部分主要是容器平臺(tái)自建或者對(duì)接的第

13、三方系統(tǒng)，比如日志、監(jiān)控、告警，代碼管理，賬戶(hù)管理等。此部分系統(tǒng)對(duì)于容器云平臺(tái)運(yùn)行至關(guān)重要，但是相關(guān)系統(tǒng)的安全設(shè)計(jì)不在本次重點(diǎn)考慮范圍內(nèi)。容器云平臺(tái)是一個(gè)多模塊組成的復(fù)雜系統(tǒng)，各個(gè)組合模塊的安全需要獨(dú)立設(shè)計(jì)以及實(shí)現(xiàn)，結(jié)合上面容器平臺(tái)的架構(gòu)，給出容器云平臺(tái)安全設(shè)計(jì)架構(gòu)圖，如下：容器云平臺(tái)安全架構(gòu)基礎(chǔ)安全設(shè)計(jì)容器運(yùn)行時(shí)安全容器運(yùn)行時(shí)通常會(huì)給管理員提供多種配置選項(xiàng)。容器運(yùn)行時(shí)配置不當(dāng)會(huì)降低系統(tǒng)的相對(duì)安全性。例如，在Linux容器主機(jī)上，經(jīng)允許的系統(tǒng)調(diào)用集合通常默認(rèn)僅限于容器安全運(yùn)行所必需的調(diào)用。如果該列表被擴(kuò)大，則被入侵的容器會(huì)讓其它容器和主機(jī)操作系統(tǒng)面臨更大風(fēng)險(xiǎn)。同樣，如果容器在特權(quán)模式下運(yùn)行，則

14、可以訪(fǎng)問(wèn)主機(jī)上的所有設(shè)備，從而讓其本質(zhì)上成為主機(jī)操作系統(tǒng)的一部分，并影響在主機(jī)操作系統(tǒng)上運(yùn)行的所有其它容器。運(yùn)行時(shí)配置不安全的一個(gè)示例是允許容器在主機(jī)上掛載敏感目錄。容器通常很少會(huì)對(duì)主機(jī)操作系統(tǒng)的文件系統(tǒng)進(jìn)行更改，而且?guī)缀醪粦?yīng)該更改控制主機(jī)操作系統(tǒng)基本功能的位置(例如，Linux容器的/boot或/etc、Windows容器的C:Windows)。如果允許遭到入侵的容器更改這些路徑，那么，也可以被用來(lái)提權(quán)并攻擊主機(jī)本身以及主機(jī)上運(yùn)行的其它容器。1安全基線(xiàn)建設(shè)安全基線(xiàn)（參照附件5和6）持續(xù)改進(jìn)建設(shè)安全基線(xiàn)檢測(cè)自動(dòng)化工具建設(shè)容器資產(chǎn)清單工具，實(shí)時(shí)洞察容器運(yùn)行狀況。2容器運(yùn)行風(fēng)格選擇容器運(yùn)行風(fēng)格方面

15、，其實(shí)有多種選擇，采用何種容器運(yùn)行風(fēng)格也是安全考慮的問(wèn)題之一： 常見(jiàn)運(yùn)行風(fēng)格：瘦容器(Thin Container):單進(jìn)程應(yīng)用的封裝，在鏡像中打包應(yīng)用。這非常適于微服務(wù)架構(gòu)應(yīng)用的服務(wù)交付。胖容器(Fat Container):多進(jìn)程應(yīng)用的封裝，在鏡像中打包應(yīng)用。容器引擎對(duì)進(jìn)程管理的特殊性，我們會(huì)利用init.d/systemd或者supervisor等來(lái)啟動(dòng)管理進(jìn)程。但是容器應(yīng)該盡可能是單一目的，容器中的進(jìn)程應(yīng)該是緊耦合的，并有一致的生命周期。比如可以將“nginx”和“php-fpm”打包在一個(gè)容器鏡像中。VM容器(VM Container):是利用容器模擬輕量級(jí)虛擬機(jī):鏡像本身不包含應(yīng)用

16、，需要利用在容器啟動(dòng)后動(dòng)態(tài)安裝和配置應(yīng)用。這是不建議的方案，會(huì)造成容器中應(yīng)用配置管理和更新的復(fù)雜性。如業(yè)務(wù)應(yīng)用暫時(shí)無(wú)法改造，需要制定過(guò)渡方案。一般而言，不建議選擇VM容器風(fēng)格。Kubernetes運(yùn)行時(shí)安全目前主流的容器云管理平臺(tái)一般基于kubernetes構(gòu)建，kubernetes平臺(tái)采用分布式架構(gòu)方式構(gòu)建，根據(jù)平臺(tái)功能由多個(gè)組件組成，如下圖。典型的組件包括api server，etcd，sheduler，controller manager， kubelet，kube-proxy，cAdvisor，Plugin networks（比如annel）等。以上組件是容器云平臺(tái)的控制（管理）平面，

17、是容器云平臺(tái)的大腦，全面洞察集群上的每一個(gè)容器和pod，并且調(diào)度新的pod，讀取和存儲(chǔ)集群中的所有私密信息，因此在通訊和數(shù)據(jù)存儲(chǔ)和傳輸方面均需要嚴(yán) 格安全包括，主要措施包括：組件安全基線(xiàn)Kubernetes安全運(yùn)行需要滿(mǎn)足必要的配置基線(xiàn)，關(guān)于基線(xiàn)建設(shè)包括： 建設(shè)安全基線(xiàn)（參照NIST規(guī)范，CIS benchmark）持續(xù)改進(jìn)建設(shè)安全基線(xiàn)檢測(cè)自動(dòng)化工具組件之間通信加密為了實(shí)現(xiàn)組件之間的安全，設(shè)計(jì)要求組件之間應(yīng)該啟用TLS，支持TLS以防止流量嗅探、驗(yàn)證服務(wù)器身份以及（對(duì)于相互TLS而言）驗(yàn)證客戶(hù)端身份。需要開(kāi)啟的TLS通訊包括： 1API Server和etcd之間API Server和Cont

18、roller Manager之間API Server和Scheduler之間4API Server 和 Kubelet 之 間5平臺(tái)管理用戶(hù)和API Server之間6Kubelet 和 容 器 之 間 7業(yè)務(wù)用戶(hù)和業(yè)務(wù)pod之間（可選）參考下圖：網(wǎng)絡(luò)安全網(wǎng)絡(luò)隔離K8s的網(wǎng)絡(luò)策略應(yīng)用于通過(guò)常用標(biāo)簽標(biāo)識(shí)的pod組。然后，使用標(biāo)簽來(lái)模擬傳統(tǒng)的分段網(wǎng)絡(luò)，這些網(wǎng)絡(luò)通常用于在多層應(yīng)用程序中隔離層：例如，可以通過(guò)特定的“段”標(biāo)簽來(lái)標(biāo)識(shí)前端和后端pod。策略控制這些段之間的流量，甚至控制來(lái)自外部源的流量。簡(jiǎn)單路由網(wǎng)絡(luò)或常用的annel網(wǎng)絡(luò)程序本身不能應(yīng)用網(wǎng)絡(luò)策略。目前Kubernetes只有幾個(gè)支持網(wǎng)絡(luò)策略

19、的網(wǎng)絡(luò)組件：Romana，Calico和Canal；其中Weave在不久的將來(lái)指示支持，Red Hat的OpenShift包括了網(wǎng)絡(luò)策略功能。因此如何容器云平臺(tái)基于OpenShift構(gòu)建會(huì)獲得OOTB的網(wǎng)絡(luò)策略功能。從網(wǎng)絡(luò)模型的流行度來(lái)看，annel的網(wǎng)絡(luò)方案最流行，市場(chǎng)占有率較大，基于calico+network policy的方案逐步成熟中，可以持續(xù)跟進(jìn)，在容器云構(gòu)建中可以在測(cè)試環(huán)境中進(jìn)行驗(yàn)證。在一些落地的方案中，容器云平臺(tái)建設(shè)過(guò)程中采用annel的方案，但是通過(guò)為不同安全級(jí)別的應(yīng)用（租戶(hù)）建設(shè)不同的集群而實(shí)現(xiàn)應(yīng)用（租戶(hù)）網(wǎng)絡(luò)隔離。南北向流量的安全對(duì)于南北向的流量，應(yīng)該引入傳統(tǒng)的網(wǎng)絡(luò)流量分

20、析控制設(shè)備，例如IPS/IDS/審計(jì)/NGFW/WAF等。東西向流量的安全東西向流量的安全也是非常關(guān)鍵的，目前可以采用的技術(shù)和產(chǎn)品比較少，但這個(gè)方面卻是非常關(guān)鍵的安全控制點(diǎn)，在沒(méi)有合適的產(chǎn)品可以替代的情況下，應(yīng)該盡量：采用Mini Knernel的容器化操作系統(tǒng)； 2非特權(quán)用戶(hù)運(yùn)行容器；3采用強(qiáng)制訪(fǎng)問(wèn)控制技術(shù)；4監(jiān)控宿主機(jī)文件系統(tǒng)的變更；5保持系統(tǒng)和組件的安全補(bǔ)丁為最新。管理安全設(shè)計(jì)管理平臺(tái)安全建設(shè)建立專(zhuān)屬CA中心，定期替換密鑰在組件TLS加密通訊的關(guān)鍵因素是證書(shū)的安全，默認(rèn)情況下，kubernetes集群搭建使用的私有CA，并且生成臨時(shí)的證書(shū)進(jìn)行TLS加密通訊，但是為了保障TLS的有效性，保

21、障CA更證書(shū)的私密以及以及降低組件證書(shū)的泄漏風(fēng)險(xiǎn)，因此建議集群的專(zhuān)屬CA中心，并且設(shè)置組件證書(shū)的有效期，在組件證書(shū)快到期的時(shí)候進(jìn)行替換。檢查根證書(shū)到期時(shí)間的命令：openssl x509 -noout -enddate -in /etc/kubernetes/ssl/kubelet-client.crt用戶(hù)權(quán)限安全管理容器云平臺(tái)的4A（即認(rèn)證Authentication、賬號(hào)Account、授權(quán)Authorization、審計(jì)Audit）管理功能設(shè)計(jì)。構(gòu)建統(tǒng)一賬戶(hù)管理平臺(tái)（UIMS）容器平臺(tái)是一個(gè)多組件組成的平臺(tái)系統(tǒng)，每個(gè)組件自成系統(tǒng)，比如鏡像管理，CI/CD平臺(tái)，日志系統(tǒng)， 監(jiān)控系統(tǒng)等，每個(gè)

22、系統(tǒng)單獨(dú)管理各自的用戶(hù)數(shù)據(jù)容易行成信息孤島，分散的用戶(hù)管理模式阻礙了平臺(tái)的協(xié)調(diào)工作，因此構(gòu)建統(tǒng)一的標(biāo)準(zhǔn)化賬戶(hù)管理體系將是必不可少的。統(tǒng)一賬戶(hù)系統(tǒng)平臺(tái)可帶來(lái)統(tǒng)一的帳號(hào)管理、身份認(rèn)證、用戶(hù)授權(quán)等基礎(chǔ)能力，為企業(yè)帶來(lái)諸如跨系統(tǒng)單點(diǎn)登錄、第三方授權(quán)登錄等基礎(chǔ)能力，為構(gòu)建開(kāi)放平臺(tái)和業(yè)務(wù)生態(tài)提供了必要條件?；诮y(tǒng)一身份治理的概念，可劃分為兩級(jí)賬戶(hù)體系、基礎(chǔ)權(quán)限模塊和基礎(chǔ)信息模塊三大模塊。其中兩級(jí)賬戶(hù)體系將賬戶(hù)分為組織實(shí)體帳號(hào)和個(gè)人實(shí)體賬戶(hù)兩大類(lèi)，個(gè)人實(shí)體從屬于組織實(shí)體，也可以不從屬任何組織實(shí)體，且個(gè)人實(shí)體可同時(shí)從屬于多個(gè)組織實(shí)體；基礎(chǔ)權(quán)限模塊將各業(yè)務(wù)系統(tǒng)的資源權(quán)限進(jìn)行統(tǒng)一管理和授權(quán)；基礎(chǔ)信息模塊用于描述組

23、織實(shí)體和個(gè)人實(shí)體的基本信息，如組織實(shí)體名稱(chēng)、地址、法人，個(gè)人實(shí)體姓名、電話(huà)號(hào)碼、性別等基礎(chǔ)信息。此外統(tǒng)一賬戶(hù)系統(tǒng)提供統(tǒng)一的API與其他系統(tǒng)對(duì)接。對(duì)于賬戶(hù)的口令需要建立嚴(yán)格的管理機(jī)制，因?yàn)橐粋€(gè)好的口令策略是防止未授權(quán)訪(fǎng)問(wèn)的一個(gè)最重要的安全屏障，減少弱口令風(fēng)險(xiǎn)是提升系統(tǒng)安全性的投入產(chǎn)出比最高的方式。建設(shè)過(guò)程中需要對(duì)容器云平臺(tái)，組織實(shí)體，個(gè)人實(shí)體等賬戶(hù)的口令進(jìn)行分類(lèi)，建立平臺(tái)超級(jí)管理員口令，組織管理員口令，個(gè)人實(shí)體口令管理辦法，典型的云平臺(tái)超級(jí)管理員口令的安全性要求最高，組織管理員次之，個(gè)人實(shí)體口令要求相對(duì)低一些，因此口令的管理措施也不同，比如云平臺(tái)超級(jí)管理員需要建設(shè)基于硬件的一次性密碼或者雙要素密

24、碼認(rèn)證機(jī)制，組織管理員密碼需要建立一次性密碼或者雙要素密碼認(rèn)證機(jī)制，個(gè)人實(shí)體密碼需要滿(mǎn)足一定密碼復(fù)雜度要求。典型口令策略，舉例：密碼至少由8個(gè)字符組成，應(yīng)該混合數(shù)字、大寫(xiě)字母、小寫(xiě)字母，以及特殊字符等；所有系統(tǒng)管理員級(jí)別的密碼必需每三個(gè)月更換一次，并依照規(guī)定進(jìn)行存檔備份。普通個(gè)人密碼六個(gè)月更換一次。用戶(hù)所使用的任何具備系統(tǒng)超級(jí)用戶(hù)權(quán)限賬號(hào)密碼必需和這個(gè)用戶(hù)其他賬號(hào)的密碼均不相同。重要的系統(tǒng)密碼比如云平臺(tái)超級(jí)管理員，組織管理員采用一次性密碼或者雙要素密碼認(rèn)證。UIMS系統(tǒng)支持完備口令使用，變更，修改，注銷(xiāo)等生命周期管理能力。另外需要通過(guò)管理規(guī)定，嚴(yán)格要求密碼使用時(shí)注意保護(hù)，比如不要把自己密碼共享

25、給他人，不要在email 中寫(xiě)密碼，不要給你上司密碼等。技術(shù)實(shí)現(xiàn)方案方面，可以通過(guò)Microsoft AD，Oracle Identity Management，OpenLdap等軟件實(shí)現(xiàn)。在一個(gè)成熟企業(yè)內(nèi)部基本上已經(jīng)具備類(lèi)似系統(tǒng)并且穩(wěn)定運(yùn)行。因此此對(duì)于容器云平臺(tái)建設(shè)來(lái)說(shuō)主要是統(tǒng)一對(duì)接，統(tǒng)一納管，統(tǒng)一管理的問(wèn)題。如果企業(yè)內(nèi)部沒(méi)有需要單獨(dú)設(shè)立子項(xiàng)目建設(shè)UIMS系統(tǒng)。構(gòu)建統(tǒng)一身份認(rèn)證平臺(tái)SSO容器云平臺(tái)實(shí)現(xiàn)統(tǒng)一身份認(rèn)證和傳統(tǒng)應(yīng)用原理一樣，區(qū)別在于kubenetes支持的身份嚴(yán)重方式有不同要求，常見(jiàn)的統(tǒng)一身份認(rèn)證方式歸納為以下兩類(lèi)：1傳統(tǒng)的Cookie+Session解決方案，有狀態(tài)會(huì)話(huà)模式； 2基

26、于令牌/票據(jù)的解決方案，無(wú)狀態(tài)交互模式。具體有：分布式Session OAuth2.0 JWTCAS上述方案各有利弊：分布式Session是老牌的成熟解決方案，但因其狀態(tài)化通信的特性與服務(wù)提倡的API導(dǎo)向無(wú)狀態(tài)通信相互違背，且共享式存儲(chǔ)存在安全隱患，因此微服務(wù)一般不太采用。OAuth2.0是業(yè)內(nèi)成熟的授權(quán)登錄解決方案，然而OA2.0提供了4種授權(quán)模式，能夠適應(yīng)多種場(chǎng)景，作為基于令牌的安全系統(tǒng)，可以廣泛用于需要統(tǒng)一身份認(rèn)證和授權(quán)的場(chǎng)景。JWT（JSON Web Token）是一種簡(jiǎn)潔的自包含的JSON聲明規(guī)范，因其分散存儲(chǔ)的特點(diǎn)而歸屬于客戶(hù)端授權(quán)模式，廣泛用于短期授權(quán)和單點(diǎn)登錄。由于JWT信息是

27、經(jīng)過(guò)簽名的，可以確保發(fā)送方的真實(shí)性，確保信息未經(jīng)篡改和偽造。但由于其自包含的客戶(hù)端驗(yàn)簽特性，令牌一經(jīng)簽發(fā)，即無(wú)法撤銷(xiāo)，因此單純采用JWT 作為統(tǒng)一身份認(rèn)證和授權(quán)方案無(wú)法滿(mǎn)足帳號(hào)統(tǒng)一登出和銷(xiāo)毀、帳號(hào)封禁和解除這幾種類(lèi)型的需求。CAS是時(shí)下最成熟的開(kāi)源單點(diǎn)登錄方案，包含CAS Server和CAS Client兩部分。CAS Server是一個(gè)war 包需要獨(dú)立部署，負(fù)責(zé)用戶(hù)認(rèn)證；CAS Client負(fù)責(zé)處理對(duì)客戶(hù)端受保護(hù)資源的訪(fǎng)問(wèn)請(qǐng)求，需要認(rèn)證時(shí)，重定向到CAS Server。值得注意的是，CAS是一個(gè)認(rèn)證框架，其本身定義了一套靈活完整的認(rèn)證流程，但其兼容主流的認(rèn)證和授權(quán)協(xié)議如OAuth2、SA

28、ML、OpenID等，因此一般采用 CAS+OAuth2的方案實(shí)現(xiàn)SSO和授權(quán)登錄。Kubernetes有三種主要的身份驗(yàn)證方法，用于和API進(jìn)行交互。官網(wǎng)列出了更多的認(rèn)證方法，但以下三種是用戶(hù)認(rèn)證常見(jiàn)的方法。靜 態(tài) 密 碼 X.509客戶(hù)端證書(shū)OpenID Connect（OIDC）其中，OpenID Connect基于OAuth 2.0協(xié)議。結(jié)合kubernetes的支持能力以及常見(jiàn)的方案，容器云平臺(tái)SSO參照實(shí)現(xiàn)方案可以采納Dex或者Keycloak。構(gòu)建最小權(quán)限授權(quán)管理機(jī)制所有對(duì)容器云的訪(fǎng)問(wèn)均通過(guò)kubernetes api server實(shí)現(xiàn)，其中訪(fǎng)問(wèn)控制的規(guī)則也是在api serve

29、r進(jìn)行設(shè)置， 在最新的Kubernetes中ABAC(基于屬性的訪(fǎng)問(wèn)控制)已被RBAC取代，ABAC不建議api server上啟用，需要使用RBAC，啟用方式是：-authorization-mode=RBAC除此之外還有以下模式：-authorization_mode=AlwaysDeny-authorization_mode=AlwaysAllow-authorization_mode=ABAC-authorization_mode=Webhook-authorization_mode=Node容器云平臺(tái)RBAC授權(quán)管理機(jī)制涉及的概念包括： 1訪(fǎng)問(wèn)對(duì)象定義：K8s對(duì)集群內(nèi)部的對(duì)象以及對(duì)象

30、上有的操作進(jìn)行了規(guī)范，比如對(duì)象包括（不含CRD對(duì)象）：Pods CongMaps Deployments Nodes Secrets Namespaces2對(duì)象操作定義：資源對(duì)象的可能存在的操作有： creategetdelete list update edit watch exec3角色/集群角色定義：角色是針對(duì)以上資源上的一組操作的集合 k8s對(duì)于role進(jìn)行了區(qū)分，分為角色(Role)和集群角色(ClusterRole)，其中在角色Role中，定義的規(guī)則只適用于單個(gè)命名空間，也就是和namespace關(guān)聯(lián)的，而ClusterRole是集群范圍內(nèi)的，因此定義的規(guī)則不受命名空間的約束。4用

31、戶(hù)/服務(wù)賬戶(hù)/組定義：在Kubernetes集群中有存在兩類(lèi)用戶(hù)：service accounts：由Kubernetes進(jìn)行管理的特殊用戶(hù)； user（普通用戶(hù)）：普通用戶(hù)是由外部應(yīng)用進(jìn)行管理的用戶(hù)。Group：組，這是用來(lái)關(guān)聯(lián)多個(gè)賬戶(hù)的，集群中有一些默認(rèn)創(chuàng)建的組，比如cluster-admin對(duì)于普通用戶(hù)，Kubernetes管理員只負(fù)責(zé)為其分配私鑰。普通用戶(hù)可能來(lái)自于Keystone或ldap中，或者甚至是存儲(chǔ)在文件中的用戶(hù)名和密碼列表。在Kubernetes中，沒(méi)有表達(dá)普通用戶(hù)的對(duì)象，因此，也就不能通過(guò)API將普通用戶(hù)添加到集群中。而Service Account是由Kubernete

32、s API管理的用戶(hù)，它們被綁定到特定的命名空間中，并由API服務(wù)器自動(dòng)創(chuàng)建或通過(guò)API調(diào)用手動(dòng)創(chuàng)建。Service Account與存儲(chǔ)在Secrets的一組證書(shū)相關(guān)聯(lián)，這些憑據(jù)被掛載到pod中，以允許集群中進(jìn)程與Kubernetes API進(jìn)行通信。API請(qǐng)求要么來(lái)自于普通用戶(hù)或Service Account，或來(lái)自于匿名請(qǐng)求。這就意味著集群內(nèi)外部的所有進(jìn)程(從來(lái)自于用戶(hù)使用kubectl輸入的請(qǐng)求，或來(lái)自于Nodes中kubelet的請(qǐng)求，或來(lái)自控制板的成員的請(qǐng)求)都需要進(jìn)行認(rèn)證才能與API server進(jìn)行交互。5 角 色 綁 定 / 集 群 角 色 綁 定 定 義 ： RoleBin

33、ding和ClusterRoleBinding：角色綁定和集群角色綁定，簡(jiǎn)單來(lái)說(shuō)就是把聲明的Subject和我們的Role進(jìn)行綁定的過(guò)程(給某個(gè)用戶(hù)綁定上操作的權(quán)限)，二者的區(qū)別也是作用范圍的區(qū)別：RoleBinding只會(huì)影響到當(dāng)前namespace下面的資源操作權(quán)限，而ClusterRoleBinding會(huì)影響到所有的namespace。在有以上定義的基礎(chǔ)上，容器云平臺(tái)的基于rbac管理模型下的權(quán)限管理方式：某一用戶(hù)(service account或者User)通過(guò)角色綁定定義了該用戶(hù)具有哪些角色，該角色詳細(xì)記錄具有對(duì)哪些對(duì)象的那些操作， 即改用戶(hù)具有了對(duì)哪些對(duì)象進(jìn)行哪些操作的能力。在容器

34、云平臺(tái)授權(quán)管理部分還是和傳統(tǒng)應(yīng)用一樣，一定授權(quán)秉承最小權(quán)限原則，對(duì)于用戶(hù)的權(quán)限進(jìn)行最小化設(shè)置，并且對(duì)于用戶(hù)的權(quán)限進(jìn)行周期性review、及時(shí)清理比不必要的用戶(hù)和權(quán)限定義。小提示：關(guān)于如何實(shí)為集群服務(wù)設(shè)置RBAC策略的最佳實(shí)踐，以及歸納典型設(shè)置可以使用audit2rbac， 從審計(jì)日志提取細(xì)粒度的RBAC策略。開(kāi)啟審計(jì)功能（非強(qiáng)制）審計(jì)功能主要包括兩部分內(nèi)容，一個(gè)是k8s api調(diào)用審計(jì)，一個(gè)是管理平臺(tái)頁(yè)面操作審計(jì)，審計(jì)記錄均以日志的形式上收到日志平臺(tái)統(tǒng)一管理，其中api審計(jì)日志通過(guò)開(kāi)啟k8s audit功能實(shí)現(xiàn)，管理平臺(tái)的審計(jì)日志通過(guò)管理平臺(tái)的實(shí)現(xiàn)方自定義實(shí)現(xiàn)。其中api server(kub

35、e-apiserver.yaml)開(kāi)啟audit日志的方式是：-feature-gates=AdvancedAuditing=true -audit-policy-file=/etc/kubernetes/pki/audit-policy.yaml -audit-log-format=json -audit-log-path=/var/log/kubernetes/kubernetes-audit-audit-log-path=/var/log/kubernetes/kubernetes-audit-audit-log-maxage=30 -audit-log-maxbackup=3 -aud

36、it-log-maxsize=100 其中audit策略在文件audit-policy.yaml定義，形如：apiVersion: audit.k8s.io/v1beta1 # This is required. kind: Policy# Dont generate audit events for all requests in RequestReceived stage. omitStages: - RequestReceived rules: # Log pod changes at RequestResponse level - level: RequestResponse reso

37、urces:- group: # Resource pods doesnt match requests to any subresource of pods, # which is consistent with the RBAC policy.resources: pods # Log pods/log, pods/status at Metadata level - level: Metadata resources:- group: resources: pods/log, pods/status # A catch-all rule to log all other requests

38、 at the Metadata level. - level: Metadata # Long-running requests like watches that fall under this rule will not # generate an audit event in RequestReceived.omitStages: - RequestReceived審計(jì)政策定義了關(guān)于應(yīng)記錄哪些事件以及應(yīng)包含哪些數(shù)據(jù)的規(guī)則。處理事件時(shí)，將按順序與規(guī)則列表進(jìn)行比較。第一個(gè)匹配規(guī)則設(shè)置事件的審計(jì)級(jí)別auditing-level。已知的審計(jì)級(jí)別有：None-符合這條規(guī)則的日志將不會(huì)記錄。Met

39、adata-記錄請(qǐng)求的metadata(請(qǐng)求的用戶(hù)、timestamp、resource、verb等等)，但是不記錄請(qǐng)求或者響應(yīng)的消息體。Request-記錄事件的metadata和請(qǐng)求的消息體，但是不記錄響應(yīng)的消息體。這不適用于非資源類(lèi)型的請(qǐng)求。RequestResponse-記錄事件的metadata，請(qǐng)求和響應(yīng)的消息體。這不適用于非資源類(lèi)型的請(qǐng)求。目前對(duì)于容器云上的API Server審計(jì)日志的支持，推薦的日志采集的方式是通過(guò)日志采集平臺(tái)將數(shù)據(jù)采集到日志中心，通常日志中心是基于大數(shù)據(jù)理念建設(shè)的海量數(shù)據(jù)存儲(chǔ)平臺(tái)，審計(jì)日志的查詢(xún)配合特定索引進(jìn)行根據(jù)關(guān)鍵字的查詢(xún)，審計(jì)日志保存內(nèi)容以及保存時(shí)間需

40、要遵從相關(guān)行業(yè)規(guī)定，通常日志內(nèi)容需包含時(shí)間、用戶(hù)、操作模塊、操作行為等信息，同時(shí)建議在線(xiàn)日志保存一個(gè)月以上，此外定期對(duì)審計(jì)日志進(jìn)行備份存檔(三級(jí)系統(tǒng)歸檔日志至少保存3個(gè)月)。租戶(hù)資源訪(fǎng)問(wèn)安全根據(jù)上面容器平臺(tái)的架構(gòu)圖，我們可以發(fā)現(xiàn)容器底層資源是以池化的方式供上層應(yīng)用進(jìn)行消費(fèi)使用的， 通過(guò)云平臺(tái)支持多租戶(hù)模型，提供了多個(gè)業(yè)務(wù)主體應(yīng)用并行運(yùn)行的能力，其實(shí)這也是云平臺(tái)的關(guān)鍵特征之一。共享的現(xiàn)狀為業(yè)務(wù)的運(yùn)行提供彈性伸縮的能力，可以實(shí)現(xiàn)對(duì)多個(gè)業(yè)務(wù)壓力削峰填谷的效果，最大限度的提升了資源的利用率。但是共享也帶了來(lái)一定的隱患，比如惡意訪(fǎng)問(wèn)，資源惡意搶占等，因此容器平臺(tái)需要實(shí)現(xiàn)容器資源隔離的能力，目前kuber

41、netes提供的能力包括：1資源的訪(fǎng)問(wèn)隔離通過(guò)namespace機(jī)制對(duì)容器云平臺(tái)進(jìn)行多租戶(hù)資源隔離，租戶(hù)內(nèi)基于RBAC模式的授權(quán)模式進(jìn)行資源的訪(fǎng)問(wèn)控制。對(duì)于資源請(qǐng)求量方面，admission control是一種多維度可擴(kuò)展的資源管理機(jī)制，每個(gè)維度通過(guò)一個(gè)admission control插件實(shí)現(xiàn)。與Kubernetes用戶(hù)認(rèn)證與授權(quán)模塊一樣，對(duì)admission control的調(diào)用也是由api server來(lái)完成的。目前支持的admission control插件，分別是NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCo

42、ndition,Priority,DefaultSeconds,DefaultStorageClass,StorageObjectInUseProtection,PersistentVolumeClaimResize,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,RuntimeClass,ResourceQuota以上插件按需激活使用，比如： -enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,Resourc eQuota Node select

43、or機(jī)制此設(shè)置是資源隔離的一種方式，但此方式并不是平臺(tái)構(gòu)建層面需要考慮的措施，需要以規(guī)范或者最佳實(shí)踐的方式通知應(yīng)用部署人員，按照規(guī)范部署實(shí)施。此功能原理是讓kubernetes集群調(diào)度器根據(jù)node selector的設(shè)置為pod資源選擇某個(gè)節(jié)點(diǎn)(如果未設(shè)置， 默認(rèn)是調(diào)度考慮的是資源足夠，并且load盡量平均)。4網(wǎng)絡(luò)隔離網(wǎng)絡(luò)資源在集群層面也是共享的，相關(guān)的隔離措施見(jiàn)前面部分。單集群和多集群在某些行業(yè)中比如金融業(yè)，監(jiān)管部門(mén)要求一個(gè)業(yè)務(wù)的前端，后端需要部署在不同的網(wǎng)絡(luò)區(qū)域中，因此容器云平臺(tái)在建設(shè)過(guò)程中，需要考慮集群跨網(wǎng)斷或者多集群部署的問(wèn)題，此外隨著一個(gè)集群的業(yè)務(wù)不斷增加， 也需要在容量上做對(duì)集

44、群拆分。因此在構(gòu)建容器云平臺(tái)時(shí)建議規(guī)劃好集群的部署形式。建議：不同環(huán)境部署多個(gè)集群，比如UAT測(cè)試，SIT測(cè)試，性能測(cè)試。不同網(wǎng)絡(luò)區(qū)域部署多個(gè)集群，比如DMZ區(qū)域，業(yè)務(wù)后臺(tái)區(qū)域。不同地域部署多個(gè)集群，比如生產(chǎn)區(qū)域和災(zāi)備區(qū)域不同業(yè)務(wù)安全級(jí)別的應(yīng)用部署在不同集群。單個(gè)集群不能太小，同時(shí)也不能太多，建議不超過(guò)128臺(tái)物理主機(jī)（48c/256G）。組件安全Kubernetes平臺(tái)本身是一個(gè)可擴(kuò)展的平臺(tái)，通過(guò)CNI支持不同的網(wǎng)絡(luò)組件，通過(guò)CSI支持不同的存儲(chǔ)組件，此外通過(guò)CRD能力支持不同的客戶(hù)化資源定義，常見(jiàn)的功能擴(kuò)展比如CI/CD，日志，監(jiān)控，告警。以上組件通過(guò)CRD的方式部署在kubernetes

45、集群內(nèi)，擴(kuò)展了容器云平臺(tái)的能力，此外在應(yīng)用層面，微服務(wù)運(yùn)行組件也以組件的方式部署在容器云平臺(tái)上。比如Spring Cloud，istio等微服務(wù)框架，因此以上組件的安全需要進(jìn)行相關(guān)的設(shè)計(jì)，鑒于容器云平臺(tái)的建設(shè)規(guī)模，各個(gè)容器云平臺(tái)的組件也不相同，本文中以最基本的CI/CD組件為例介紹組件的安全設(shè)計(jì)要求：1數(shù)據(jù)與環(huán)境隔離：不同項(xiàng)目、不同團(tuán)隊(duì)的數(shù)據(jù)要保證隔離，一個(gè)項(xiàng)目的多套環(huán)境，多套介質(zhì)同樣要保證隔離，比如介質(zhì)庫(kù)，首先各項(xiàng)目的介質(zhì)庫(kù)要隔離，一個(gè)項(xiàng)目的開(kāi)發(fā)庫(kù)、測(cè)試庫(kù)、投產(chǎn)庫(kù)同樣要隔離，測(cè)試通過(guò)的介質(zhì)，則通過(guò)可控的同步手段發(fā)到投產(chǎn)庫(kù)。另外比如部署引擎，什么引擎可針對(duì)什么環(huán)境進(jìn)行部署操作，也是嚴(yán)格控制的，

46、防止環(huán)境操作越權(quán)。2UI與API的權(quán)限控制：對(duì)界面的菜單、按鈕進(jìn)行權(quán)限控制，對(duì)后臺(tái)api的訪(fǎng)問(wèn)權(quán)限進(jìn)行權(quán)限控制，其中賬戶(hù)部分需要對(duì)接統(tǒng)一的LDAP系統(tǒng)。3可審計(jì)：對(duì)于什么人在什么時(shí)候在平臺(tái)上做了什么，在動(dòng)作前后資源產(chǎn)生了這樣的變更，比如部署的操作，什么人審批還是可自動(dòng)執(zhí)行，部署完成后由誰(shuí)確認(rèn)(亦或是通過(guò)自動(dòng)化測(cè)試確認(rèn))，這些關(guān)鍵事項(xiàng)， 需要結(jié)合不同團(tuán)隊(duì)的實(shí)際情況進(jìn)行不同的個(gè)性化配置。4平滑升級(jí)：組件的升級(jí)應(yīng)該不影響容器云平臺(tái)的影響。應(yīng)用安全容器鏡像安全眾所周知，應(yīng)用在容器云平臺(tái)存在的形式時(shí)鏡像，因此容器鏡像的安全是應(yīng)用安全的基礎(chǔ)，對(duì)于容器鏡像安全主要包括兩部分內(nèi)容，鏡像介質(zhì)安全和鏡像運(yùn)行(策略

47、)安全。鏡像介質(zhì)安全每個(gè)容器鏡像都是由一系列的“鏡像層”組成的，為了保障使用的鏡像是純凈的、未被污染的，需要對(duì)其解包后安全分析掃描以發(fā)現(xiàn)安全漏洞。從CVE漏洞、NVD漏洞，木馬病毒、可疑歷史操作、敏感信息泄露以及是否是可信任鏡像等多個(gè)維度對(duì)鏡像文件進(jìn)行深度分析。因此鏡像安全必須構(gòu)建一套完整的鏡像安全掃描設(shè)施。另外鏡像作為應(yīng)用的存在形式，鏡像需要在開(kāi)發(fā)環(huán)境，測(cè)試環(huán)境，生產(chǎn)環(huán)境間進(jìn)行傳遞，并且根據(jù)鏡像的不同生命階段，鏡像會(huì)存在鏡像庫(kù)中和下載運(yùn)行宿主機(jī)上。因此在鏡像傳遞和鏡像保存方面需要考慮鏡像的一致性問(wèn)題，需要有必要的手段防止鏡像被篡改。鏡像運(yùn)行(策略)安全容器云平臺(tái)應(yīng)需要支持在容器啟動(dòng)過(guò)程中，當(dāng)

48、發(fā)現(xiàn)有安全問(wèn)題的容器鏡像時(shí)，通過(guò)禁止容器運(yùn)行來(lái)達(dá)到系統(tǒng)安全運(yùn)行的能力，容器平臺(tái)需要支持的安全策略如下（部分）:發(fā)現(xiàn)鏡像以root用戶(hù)運(yùn)行禁止運(yùn)行發(fā)現(xiàn)鏡像有指定的安全級(jí)別的漏洞禁止運(yùn)行發(fā)現(xiàn)鏡像內(nèi)有指定某CVE漏洞禁止運(yùn)行發(fā)現(xiàn)鏡像內(nèi)有木馬病毒禁止運(yùn)行發(fā)現(xiàn)鏡像內(nèi)有特定的軟件包版本禁止運(yùn)行發(fā)現(xiàn)鏡像內(nèi)有非信任鏡像禁止運(yùn)行發(fā)現(xiàn)鏡像內(nèi)有私有證書(shū)禁止運(yùn)行以上能力需要在基礎(chǔ)容器云平臺(tái)能力的基礎(chǔ)上進(jìn)行增強(qiáng)實(shí)現(xiàn)，另外可以通過(guò)采購(gòu)業(yè)內(nèi)相關(guān)產(chǎn)品實(shí)現(xiàn)，如果構(gòu)建容器云平臺(tái)有廠(chǎng)商支持，此部分也可以作為POC的關(guān)注點(diǎn)。鏡像庫(kù)建設(shè)對(duì)于鏡像庫(kù)建設(shè)方案包括1采用商用的鏡像倉(cāng)庫(kù)，并且啟用鏡像漏洞掃描功能，2自建鏡像倉(cāng)庫(kù)，但是構(gòu)建一套完

49、整的鏡像掃描工具，對(duì)于鏡像進(jìn)行離線(xiàn)掃描，并且形成整改措施。鏡像倉(cāng)庫(kù)對(duì)于容器云平臺(tái)來(lái)說(shuō)至關(guān)重要，因此鏡像庫(kù)安全需要從以下方面進(jìn)行考慮1與容器云平實(shí)現(xiàn)統(tǒng)一賬戶(hù)管理，支持多租戶(hù)管理。2支持TLS加密訪(fǎng)問(wèn)，訪(fǎng)問(wèn)權(quán)限控制以保證鏡像安全。3冗余、高可用的架構(gòu)，數(shù)據(jù)持久性，支持全鏈路數(shù)據(jù)加密，保障數(shù)據(jù)安全。4擁有海量的存儲(chǔ)能力，隨時(shí)隨地可以實(shí)現(xiàn)對(duì)容器鏡像的下載、管理。鏡像簽名對(duì)于鏡像一致性保障方面，一般的方案建立鏡像簽名機(jī)制。容器鏡像簽名允許用戶(hù)添加數(shù)字指紋到鏡像中。這個(gè)指紋隨后可被加密算法測(cè)試驗(yàn)證。這使得容器鏡像的用戶(hù)可以驗(yàn)證其來(lái)源，進(jìn)而防止了鏡像的惡意篡改，可行的方案有DTR（Docker Trust

50、Repository）/DCT（Docker Content Trust）方案和harbor/notary 方案。DTR/DCT方案中，鏡像校驗(yàn)和用來(lái)保證鏡像的完整性，以預(yù)防可能出現(xiàn)的鏡像破壞。registry下的每一個(gè)鏡像都對(duì)應(yīng)擁有自己的manifest文件以及該文件本身的簽名。其中的信息包括鏡像所在的命名空間、鏡像在此倉(cāng)庫(kù)下對(duì)應(yīng)的標(biāo)簽、鏡像校驗(yàn)方法及校驗(yàn)和、鏡像形成時(shí)的運(yùn)行信息以及manifest文件本身的簽名。容器鏡像安全Secret應(yīng)用啟動(dòng)過(guò)程中可能需要一些敏感信息，比如訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的用戶(hù)名密碼或者秘鑰。將這些信息直接保存在容器鏡像中顯然不妥，Kubernetes提供的解決方案是Secr

51、et。Secret會(huì)以密文的方式存儲(chǔ)數(shù)據(jù)，避免了直接在配置文件中保存敏感信息。Secret會(huì)以Volume的形式被mount到Pod，容器可通過(guò)文件的方式使用Secret中的敏感數(shù)據(jù)；此外，容器也可以環(huán)境變量的方式使用這些數(shù)據(jù)。常見(jiàn)敏感信息包括關(guān)鍵的環(huán)境變量，比如數(shù)據(jù)鏈接密碼信息，TLS證書(shū)信息，鏡像庫(kù)認(rèn)證信息等。Vault眾所周知，即使使用了k8s secret進(jìn)行敏感信息的保存，其實(shí)默認(rèn)情況secret的信息只是做了base64編碼，通過(guò)k8s api還是可以獲得secret存儲(chǔ)的敏感信息的，Vault產(chǎn)品作為企業(yè)級(jí)的secret管理工具，滿(mǎn)足了客戶(hù)在業(yè)務(wù)上云過(guò)程中的安全強(qiáng)需求。因此建議在

52、容器云平臺(tái)建設(shè)中進(jìn)行采用。其主要的應(yīng)用場(chǎng)景：1作為部署在Kubernetes集群中的應(yīng)用對(duì)外提供秘鑰管理服務(wù)，支持與多家主流云廠(chǎng)商秘鑰服務(wù)以及多種secrets形式的對(duì)接，支持多種數(shù)據(jù)庫(kù)服務(wù)的存儲(chǔ)對(duì)接，同時(shí)支持多種認(rèn)證形式的對(duì)接。作為一個(gè)公共的加密服務(wù)（Encryption as a Service）而不做后端存儲(chǔ)的對(duì)接，幫助用戶(hù)應(yīng)用剝離繁瑣的加密加解密邏輯。面向政府、金融等對(duì)數(shù)據(jù)安全規(guī)格有很高要求的客戶(hù)，Vault支持基于Two-man原則利用私鑰分割算法對(duì)后端服務(wù)進(jìn)行加解封，并結(jié)合k8s的高可用部署形態(tài)為企業(yè)提供更加安全可靠的secret管理能力。Vault作為一個(gè)在Kubernetes集

53、群上直接運(yùn)行的安全應(yīng)用，任何一個(gè)面向k8s的應(yīng)用工具都可以利用其安全能力。容器服務(wù)訪(fǎng)問(wèn)安全業(yè)務(wù)應(yīng)用在容器云平臺(tái)中Service的方式存在。Service是Kubernetes最核心的資源對(duì)象之一，通過(guò)它可以為一組具備相同功能的容器應(yīng)用提供一個(gè)統(tǒng)一的訪(fǎng)問(wèn)入口地址，并將請(qǐng)求負(fù)載分發(fā)到后端的各個(gè)容器應(yīng)用上。這一點(diǎn)與傳統(tǒng)IT基礎(chǔ)架構(gòu)中F5等負(fù)載均衡設(shè)備將訪(fǎng)問(wèn)請(qǐng)求負(fù)載分發(fā)到后端功能相同的應(yīng)用上類(lèi)似， Kubernetes集群中每個(gè)節(jié)點(diǎn)上運(yùn)行的kube-proxy其實(shí)就是一個(gè)智能的軟件負(fù)載均衡器，它負(fù)責(zé)把對(duì)Service 的請(qǐng)求轉(zhuǎn)發(fā)到后端的某個(gè)pod實(shí)例上，并在內(nèi)部實(shí)現(xiàn)服務(wù)的負(fù)載均衡與會(huì)話(huà)保持機(jī)制。Kub

54、ernetes提供了三種主要方案，分別是NodePort、LoadBalancer、Ingress。NodePort NodePort的實(shí)現(xiàn)方式是在每個(gè)節(jié)點(diǎn)上為需要外部訪(fǎng)問(wèn)的Service開(kāi)啟一個(gè)對(duì)應(yīng)的TCP監(jiān)聽(tīng)端口，外部系統(tǒng)用:可以從集群外部訪(fǎng)問(wèn)一個(gè)NodePort服務(wù)，NodePort服務(wù)會(huì)路由到ClusterIP，通過(guò)kube-proxy轉(zhuǎn)發(fā)至后端的容器，完成對(duì)服務(wù)的訪(fǎng)問(wèn)。LoadBalancer LoadBalancer是Kubernetes深度結(jié)合云平臺(tái)的一個(gè)組件，使用它構(gòu)建服務(wù)時(shí)，實(shí)際上是向底層IaaS申請(qǐng)創(chuàng)建一個(gè)負(fù)載均衡來(lái)實(shí)現(xiàn)。IaaS網(wǎng)絡(luò)和容器網(wǎng)絡(luò)在不同云平臺(tái)的融合方案不同，因

55、此LoadBalancer和云平臺(tái)的網(wǎng)絡(luò)方案深度耦合，只能在特定的云平臺(tái)上使用，局限性較大。IngressIngress可以很好的解決LoadBalancer和NodePort的限制。它由3個(gè)組件組成：Ingress策略集、Ingress Controller和反向代理負(fù)載均衡器(如Nginx。Ingress策略集定義了集群外的流量到達(dá)集群內(nèi)的Service的規(guī)則。Ingress Controller與Kubernetes的API交互，實(shí)時(shí)感知后端Service、pod的變化，再結(jié)合Ingress策略集生成配置，然后更新反向代理負(fù)載均衡器的配置，實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)與更新。反向代理負(fù)載均衡器對(duì)集群

56、外流量進(jìn)行負(fù)載分發(fā)?，F(xiàn)有的Kubernetes版本已將Nginx與Ingress Controller合并為一個(gè)組件Nginx-Ingress-Control- ler，無(wú)需單獨(dú)部署Nginx。但Kubernetes原生Ingress是一個(gè)七層負(fù)載均衡技術(shù)，僅適用于http服務(wù)。另外， 其并未解決Kubernetes環(huán)境下，不同租戶(hù)的服務(wù)隔離問(wèn)題。除了k8s原生支持方案以外，F(xiàn)5公司提供了另外一種方案： F5 CC+VE方案該解決方案包含2個(gè)組件，VE(Virtual Edition)和CC(Container Connector)。VE是F5LTM的軟件化商業(yè)產(chǎn)品，可以安裝在虛擬機(jī)或者物理機(jī)

57、上，其功能與硬件設(shè)備完全一致。CC是F5解決方案的一個(gè)關(guān)鍵組件， 為用戶(hù)提供了企業(yè)級(jí)支撐，同時(shí)也是開(kāi)源產(chǎn)品，用戶(hù)可以根據(jù)自己的需要對(duì)CC進(jìn)行功能擴(kuò)展。該方案利用CC與Kubernetes進(jìn)行API交互，實(shí)現(xiàn)與容器平臺(tái)的聯(lián)動(dòng)，滿(mǎn)足容器應(yīng)用的靈活性需求；配置上采用Cong- Map進(jìn)行負(fù)載均衡策略下發(fā)，實(shí)現(xiàn)在Kubernetes層面進(jìn)行F5策略配置工作；網(wǎng)絡(luò)架構(gòu)上采用VE直接對(duì)集群中的pod進(jìn)行負(fù)載分發(fā)，減少網(wǎng)絡(luò)層次，提升負(fù)載均衡性能；同時(shí)，通過(guò)將Kubernetes的namespace與VE 的partition映射，實(shí)現(xiàn)不同容器租戶(hù)負(fù)載均衡資源的隔離，此方案架構(gòu)如下圖：以上方案中，F(xiàn)5方案中實(shí)

58、現(xiàn)了基于api的TLS證書(shū)管理能力以及F5商用產(chǎn)品的負(fù)載均衡處理能力，是一種不錯(cuò)的應(yīng)用安全入訪(fǎng)訪(fǎng)問(wèn)控制方案。應(yīng)用證書(shū)管理隨著零信任安全模型的普及，業(yè)務(wù)系統(tǒng)實(shí)現(xiàn)全站HTTPS化，加密用戶(hù)與業(yè)務(wù)間的交互訪(fǎng)問(wèn)已經(jīng)成為安全的必選項(xiàng)，為了提供業(yè)務(wù)快速安全的上云的需要，需要在容器云平臺(tái)上提供一站式SSL證書(shū)解決方案，支持包括云上客戶(hù)自己上傳任意機(jī)構(gòu)簽發(fā)的SSL證書(shū)，統(tǒng)一管理不同渠道證書(shū)，以及將證書(shū)一鍵部署到入防負(fù)載均衡服務(wù)的能力。WEB應(yīng)用入侵檢測(cè)隨著零信任安全模型的普及，業(yè)務(wù)系統(tǒng)實(shí)現(xiàn)全站HTTPS化，加密用戶(hù)與業(yè)務(wù)間的交互訪(fǎng)問(wèn)已經(jīng)成為安全的必選項(xiàng)，為了提供業(yè)務(wù)快速安全的上云的需要，需要在容器云平臺(tái)上提供

59、一站式SSL證書(shū)解決方案，支持包括云上客戶(hù)自己上傳任意機(jī)構(gòu)簽發(fā)的SSL證書(shū)，統(tǒng)一管理不同渠道證書(shū)，以及將證書(shū)一鍵部署到入防負(fù)載均衡服務(wù)的能力。WEB應(yīng)用入侵檢測(cè)在容器云環(huán)境下，依然很重要，應(yīng)用入侵防御主要的考慮點(diǎn)如下：Iptables隔離，通過(guò)在宿主機(jī)側(cè)對(duì)網(wǎng)絡(luò)集群外部做基于Iptables的隔離策略，可以限制攻擊者對(duì)“容器在宿主機(jī)所映射端口”的訪(fǎng)問(wèn)，縮小受攻擊面。部署軟WAF，通過(guò)在網(wǎng)絡(luò)集群的流量入口處做軟WAF的部署(形態(tài)可以是宿主機(jī)軟件或者容器)，可以在此處阻斷、發(fā)現(xiàn)部分惡意流量。部署RASP，通過(guò)在Java、PHP服務(wù)器容器內(nèi)部部署RASP產(chǎn)品，可以用之作為保護(hù)的最后一環(huán)， 作為網(wǎng)絡(luò)治理的一個(gè)補(bǔ)充小點(diǎn)。Webshell掃描，通過(guò)在宿主機(jī)側(cè)通過(guò)Webshell掃描引擎掃描來(lái)自Docker容器的“Web應(yīng)用程序文件”(這些文件可通過(guò)“docker cp”命令或者“動(dòng)態(tài)掛載”機(jī)制獲得)，有助于發(fā)現(xiàn)攻擊者植入的Webshell。日志分析，通過(guò)在宿主