容器云技術(shù)在彈性和效率上的巨大優(yōu)勢，使其日益成為主流的IT基礎(chǔ)設(shè)施。根據(jù)Gartner的預(yù)測，到2025年，云原生平臺將成為95%以上的新數(shù)字化計劃的基礎(chǔ)，而云原生平臺中的很大比例指的是容器云平臺。伴隨著容器云的建設(shè)，其安全的重要性也水漲船高，安全廠商與各企業(yè)的安全運(yùn)營部門都開始在這個方向投入。

容器云安全不止是容器本身的安全，還包括鏡像安全、編排（如K8s）安全、微服務(wù)安全、宿主操作系統(tǒng)風(fēng)險等。其防御手段也不僅僅是針對運(yùn)行時容器進(jìn)行檢測響應(yīng)，也包括對開發(fā)生成的制品進(jìn)行檢查，防患于未然。雖然安全左移并非新概念，但容器云的安全建設(shè)相對傳統(tǒng)云平臺的安全建設(shè)，會更注重全生命周期。

容器云安全現(xiàn)狀

• 安全風(fēng)險不容樂觀

據(jù)《Sysdig 2022 云原生安全和使用報告》顯示，超過75%的運(yùn)行容器存在高危或嚴(yán)重漏洞、62%的容器被檢測出包含shell命令、76%的容器使用root權(quán)限運(yùn)行。在我們之前接觸的用戶案例中，也存在不少企業(yè)的容器云允許kubelet被匿名訪問，或者整個容器云平臺沒有任何防護(hù)措施，處于“裸奔”狀態(tài)。諸多信息都表明企業(yè)的容器云存在較大安全風(fēng)險，需要謹(jǐn)慎對待。

早在2018年，某著名車企部署在AWS上的容器集群曾遭黑客植入挖礦木馬。2021年初，又有一家企業(yè)的Kubernetes集群遭攻擊團(tuán)伙TeamTNT入侵并植入挖礦木馬。2021年4月1日，程序?qū)徲嬈脚_Codecov遭攻擊，黑客利用Codecov的Docker鏡像創(chuàng)建過程中出現(xiàn)的錯誤，非法獲取腳本權(quán)限并對其進(jìn)行修改，最后將信息發(fā)送到 Codecov 基礎(chǔ)架構(gòu)之外的第三方服務(wù)器，影響數(shù)萬名客戶。

從重保的角度來看，相對往年2022年8月份舉行的攻防演練（HVV）明確了容器失陷的扣分標(biāo)準(zhǔn)，每失陷一個容器扣10分。基于集群與容器的數(shù)量關(guān)系，如果整個集群被攻陷，丟分會非常嚴(yán)重。

由此我們可以得出結(jié)論，不管是真實(shí)的網(wǎng)絡(luò)攻擊，還是攻防演練，亦或是合規(guī)檢查，容器云安全均處于重要位置，企業(yè)安全建設(shè)部門應(yīng)當(dāng)給予足夠重視。

• 標(biāo)準(zhǔn)規(guī)范不斷成熟

早期的容器云安全是缺少國內(nèi)規(guī)范和標(biāo)準(zhǔn)的，廠商與用戶只能參考CIS的兩個Benchmark，包括K8S和Docker。但隨著需求旺盛，相關(guān)機(jī)構(gòu)開始組織行業(yè)專家編寫相關(guān)規(guī)范，以指導(dǎo)相應(yīng)的安全建設(shè)和產(chǎn)品研發(fā)。

• 2020年，信通院發(fā)布容器安全標(biāo)準(zhǔn)，并據(jù)此推出可信容器云認(rèn)證；
• 2021年，信通院發(fā)布云原生架構(gòu)安全白皮書；
• 2022年，CSA大中華區(qū)發(fā)布了云原生安全技術(shù)規(guī)范（CNST），同時聯(lián)合公安部第三研究所發(fā)布了針對云原生和云應(yīng)用的安全可信認(rèn)證。
• 2022 年，公安三所編寫等保2.0的容器云安全增補(bǔ)部分（征求意見稿）。

除此之外，各個行業(yè)或企業(yè)也在根據(jù)自身特點(diǎn)進(jìn)行標(biāo)準(zhǔn)制定。

標(biāo)準(zhǔn)規(guī)范的推出和成熟，側(cè)面反映了其必要性和重要性，也為產(chǎn)品研發(fā)和用戶采購指明了方向，有較強(qiáng)的借鑒意義，降低了行業(yè)摸索走彎路的成本。容器云安全產(chǎn)品應(yīng)該包括哪些功能，為用戶創(chuàng)造哪些價值變得相對比較明確。

• 各家產(chǎn)品競爭激烈

今年RSAC創(chuàng)新沙盒大賽10強(qiáng)里面，有4家參賽企業(yè)選擇了容器云安全相關(guān)領(lǐng)域，足以讓我們感受到這個細(xì)分領(lǐng)域的熱度。而在國內(nèi)，我們看到有大約二十幾家企業(yè)進(jìn)入到這個賽道。其中既有奇安信、啟明、綠盟這樣的傳統(tǒng)安全廠商，也有青藤這樣的后起之秀，還有以小佑為典型的創(chuàng)業(yè)公司。筆者估計，未來會有更多的廠商參與進(jìn)來。容器云安全的未來市場被看好，因此在需求還未完全釋放的階段，競爭已經(jīng)提前進(jìn)入了白熱化。同時，競爭促使產(chǎn)品功能的同質(zhì)化也日趨嚴(yán)重。

容器云安全產(chǎn)品探討

作為容器云安全細(xì)分領(lǐng)域的老兵，筆者曾見過多家廠商的容器云安全產(chǎn)品，也曾親自主導(dǎo)設(shè)計過某廠商的容器安全產(chǎn)品，后來又轉(zhuǎn)到某甲方客戶運(yùn)營容器云安全。基于這幾年的個人經(jīng)驗(yàn)，用幾個話題拋磚引玉，供大家參考。

• 三大核心功能?

從用戶需求出發(fā)，容器云安全產(chǎn)品應(yīng)具備的功能應(yīng)至少包含 “合規(guī)檢查” 、 “鏡像掃描”和 “入侵檢測與響應(yīng)”。這是最核心的需求，也是目前所有廠商的容器云安全產(chǎn)品都具備的功能。

鏡像掃描：由于“不可變基礎(chǔ)設(shè)施”的特性，對容器的漏掃可以通過鏡像掃描來實(shí)現(xiàn)，對容器的加固也需要通過鏡像加固來實(shí)現(xiàn)。鏡像掃描有一些不錯的開源工具，例如Clair、Trivy，但這些開源工具的能力是不夠的。一方面，掃描的深度應(yīng)當(dāng)細(xì)化到組件層面，與SCA功能結(jié)合起來。另一方面，掃描出來的漏洞如何管理，漏洞影響了哪些資產(chǎn)，哪些漏洞應(yīng)該被優(yōu)先修復(fù)，都是容器云安全建設(shè)中需要考慮的問題。商業(yè)產(chǎn)品的功能完整度上普遍較好一些，但也參差不齊。

入侵檢測：入侵檢測是網(wǎng)絡(luò)安全攻防演練中最有價值的能力，但也是有難度的功能。容器云面臨的攻擊手段，與主機(jī)有很大相似性，例如反彈shell、賬號提權(quán)都是常見方式。兩者也有一定區(qū)別，因此MITRE針對容器場景單獨(dú)推出了一版ATT&CK框架，用于指導(dǎo)容器云安全建設(shè)。但在實(shí)際做入侵檢測時，大多數(shù)容器安全產(chǎn)品只能基于單條指令去匹配規(guī)則，而不能基于上下文聯(lián)系進(jìn)行綜合分析，自然也無法將檢測到的攻擊方式映射到攻擊鏈的具體階段。此外，大多數(shù)容器云安全產(chǎn)品的入侵檢測準(zhǔn)確率也有待提升。

合規(guī)檢查：合規(guī)檢查是一個容易實(shí)現(xiàn)的功能，比產(chǎn)品實(shí)現(xiàn)更需要關(guān)注的是如何根據(jù)企業(yè)自身情況建立一套合適的容器云安全基線。在這一套安全基線中，除了包含k8s與容器，也可以考慮運(yùn)行在容器云環(huán)境中的數(shù)據(jù)庫安全基線和其他各類中間件安全基線。

• 微隔離?

作為2019-2021年的熱點(diǎn)，市面上涌現(xiàn)了大量的零信任產(chǎn)品或零信任方案。而作為三大核心技術(shù)之一的微隔離，自然也不會缺席容器安全領(lǐng)域。基本上國內(nèi)的主流容器安全產(chǎn)品，均提供了“微隔離”的一級菜單，其實(shí)現(xiàn)方式往往是通過Kubernetes自帶的NetworkPolicy或者Linux自帶的IPtables。作為一種技術(shù)，NetworkPolicy能提供細(xì)粒度的網(wǎng)絡(luò)層隔離，理論上能夠滿足大多數(shù)場景下的配置需求。但是在實(shí)際運(yùn)營中，大量的繁瑣的配置工作使得該功能特性的落地非常困難。同一個業(yè)務(wù)軟件的內(nèi)部之間的各種通信，不同業(yè)務(wù)軟件之間各種通信，都需要預(yù)先配置在白名單中。稍有不慎，便有可能因?yàn)槿鄙倥渲脤?dǎo)致業(yè)務(wù)受影響。為了保密性而影響可用性自然是得不償失，因此現(xiàn)有微隔離產(chǎn)品將重點(diǎn)放在阻斷是不合適的，更適合在安全運(yùn)營中推廣的應(yīng)該是告警模式。

第一步：以業(yè)務(wù)應(yīng)用為單位，對容器的網(wǎng)絡(luò)行為進(jìn)行學(xué)習(xí)，構(gòu)建網(wǎng)絡(luò)行為模型；

第二步：在構(gòu)建完成模型后，對于偏離的流量進(jìn)行告警；

第三步：運(yùn)維人員對告警進(jìn)行排查，確認(rèn)是準(zhǔn)確告警還是誤報。如果屬于誤報則對模型進(jìn)行修正；如果是攻擊事件，則進(jìn)行阻斷處置；

上述方案有兩個優(yōu)點(diǎn)，一是沒有繁雜的配置，減少了運(yùn)維人員的工作量；二是只產(chǎn)生告警不影響業(yè)務(wù)可用性。這個方案也存在挑戰(zhàn)和技術(shù)難度，構(gòu)建的網(wǎng)絡(luò)行為模型如果不準(zhǔn)確，有可能產(chǎn)生大量誤報，使得安全運(yùn)營人員疲于應(yīng)對，結(jié)果仍然會棄用此特性。

• 部署形態(tài)

容器云安全產(chǎn)品的部署形態(tài)，可以有四種選擇，主機(jī)Agent、平行容器、sidecar容器、無Agent。

國外的容器安全產(chǎn)品，例如Aqua、Twistlock、Stackrox、Neuvector，多采用平行容器的部署形態(tài)。國內(nèi)的安全廠商，如果原來有主機(jī)安全產(chǎn)品，則傾向于在主機(jī)Agent上進(jìn)行擴(kuò)展，一個Agent同時負(fù)責(zé)主機(jī)安全與容器安全；如果是新創(chuàng)業(yè)的容器安全廠商，則傾向于采用平行容器的方式聚焦容器安全。

從用戶的角度，少安裝一個Agent意味著少占用資源，同一個平臺意味著管理成本的降低。所以大多數(shù)場景下，主機(jī)Agent的部署方式會更受歡迎。但是平行容器也有明確的支持者：

• 主機(jī)安全職責(zé)與容器安全職責(zé)歸屬不同部門；
• 已采購的主機(jī)安全產(chǎn)品不具備容器安全能力，迫使其必須單獨(dú)采購。

采用sidecar容器部署形態(tài)的產(chǎn)品會少很多，一方面是由于其資源占用較多，另一方面是由于對業(yè)務(wù)Pod存在一定的侵入性，使得該形態(tài)的安全產(chǎn)品在推廣時面臨較大阻力。如果是借助Istio這類Service Mesh技術(shù)，則必須承認(rèn)當(dāng)前Istio的普及程度也非常有限。

另一種比較有意思的是無Agent部署方式，Orca是其中的代表廠商，Orca的方案里，云主機(jī)上不會安裝Agent，但會對云環(huán)境中的塊存儲進(jìn)行快照，然后通過快照重建完整的“上下文”，對其進(jìn)行安全掃描和分析。這個技術(shù)方案叫SideScanning，其特點(diǎn)如下所示。優(yōu)點(diǎn)與缺點(diǎn)都非常明顯，但筆者不太推薦這個方案。

• 無代理，對塊存儲也只需要 “只讀權(quán)限”，所以不會對業(yè)務(wù)造成影響；
• 部署速度快，通常半個小時內(nèi)完成部署；
• 對資產(chǎn)覆蓋完整，具有完整的上下文；
• 集多種安全功能于一體，包括控制平面和數(shù)據(jù)平面的安全；
• 準(zhǔn)實(shí)時，而非實(shí)時分析；
• 只具備分析能力，不具備攔截和阻斷能力

總結(jié)一下，筆者認(rèn)為相對主流的方案是主機(jī)Agent和平行容器兩種方案。至于這兩種方案之間如何選擇，用戶可以根據(jù)自身場景進(jìn)行合理的選擇。

• 開源社區(qū)

云原生社區(qū)非常活躍，孵化了大量合規(guī)與安全類的開源項(xiàng)目，例如大名鼎鼎的掃描工具Clair、Trivy，集群合規(guī)檢查Kube-bench、通用策略引擎OPA。在去年，紅帽收購 StackRox、SUSE收購NeuVector后分別將這兩款優(yōu)秀的容器安全產(chǎn)品開源。基于此狀態(tài)，容器安全產(chǎn)品開發(fā)的技術(shù)門檻被大大降低，參與此賽道的廠商可能會增多。一些有安全開發(fā)能力的企業(yè)也可以基于開源工具進(jìn)行二次開發(fā)，從而節(jié)省采購成本。

用戶選擇采購商業(yè)產(chǎn)品，還是基于開源自研，與多種因素有關(guān)，在此不做過多探討。但筆者建議商業(yè)產(chǎn)品的開發(fā)商減少對開源安全工具的依賴。開源代碼加上簡單封裝，可以快速得到新的功能擴(kuò)展，但如果沒有對源代碼進(jìn)行詳細(xì)研究，便無法避開里面的坑，無法打造真正的優(yōu)秀產(chǎn)品。

容器云安全發(fā)展趨勢

隨著需求的持續(xù)增長，競爭的加劇，容器安全廠商需要繼續(xù)優(yōu)化產(chǎn)品。用戶也會根據(jù)實(shí)際安全運(yùn)營中的反饋，在容器云安全建設(shè)中進(jìn)行調(diào)整。按照筆者的認(rèn)知，無論是容器云安全產(chǎn)品，還是容器云安全建設(shè)，都有很大的進(jìn)步空間。

• 深度發(fā)展?

容器云安全作為新興交叉領(lǐng)域，需要的人才既要懂容器云，又要懂網(wǎng)絡(luò)安全。因此，其學(xué)習(xí)曲線較陡峭。這也導(dǎo)致了人才的缺乏。無論是甲方客戶還是乙方廠商，在招聘這方面的人才時都不容易。而由于容器安全人才的缺乏，使得無論用戶還是供應(yīng)商，在產(chǎn)品 PK 時很容易流于表面，比拼功能數(shù)量，而非深入測試產(chǎn)品的安全檢測能力與性能。在產(chǎn)品采購后的安全運(yùn)營中，追求“不出事”，而不是防御的有效性。

未來，隨著越來越多人了解容器云安全，以及真實(shí)的增長的安全需求，會促使人們關(guān)注點(diǎn)回歸問題本質(zhì)——是否能檢測和攔截大多數(shù)容器攻擊，保護(hù)容器云上的數(shù)據(jù)安全。要實(shí)現(xiàn)這一目標(biāo)，并不意味著功能模塊的增加，而是比拼安全研發(fā)團(tuán)隊的沉淀。

• 如何能準(zhǔn)確識別更多的漏洞
• 如何能準(zhǔn)確識別更多的已知攻擊
• 如何有效防御未知攻擊
• 如何同時降低漏報率與誤報率
• 對檢測的問題是否能夠自動攔截 / 加固 / 修復(fù)

要實(shí)現(xiàn)更大的進(jìn)展，當(dāng)前大多數(shù)容器安全產(chǎn)品采用的用戶態(tài)進(jìn)程檢測是存在不足的，也許內(nèi)核態(tài)的ebpf技術(shù)能夠發(fā)揮作用，也許對“指令序列”的檢測能夠發(fā)現(xiàn)更細(xì)的問題，這都有待于進(jìn)一步的調(diào)研和驗(yàn)證。

• 廣度發(fā)展?

2021年，Gartner提出了新的概念CNAPP- 云原生應(yīng)用保護(hù)平臺。不同于容器云安全重點(diǎn)關(guān)注運(yùn)行時安全，CNAPP覆蓋了云原生應(yīng)用的全生命周期，包括代碼安全，軟件成分分析等等。

CNAPP的提出反映了整合的理念。對于用戶而言，使用統(tǒng)一的平臺，而非零散的煙囪式工具，可以有更完整的安全視角。但這個場景可能并非適用于所有用戶，因?yàn)橛行┯脩舻难邪l(fā)測試環(huán)境與生產(chǎn)環(huán)境是網(wǎng)絡(luò)隔離的。用戶在建設(shè)容器安全時，可以結(jié)合自身實(shí)際情況，選擇合適的建設(shè)方案。

結(jié)束語

綜上所述，容器云安全領(lǐng)域面臨著很大挑戰(zhàn)，同時也充滿了機(jī)會。但毫無疑問，它會越來越重要，也會越來越好。歡迎感興趣的讀者共同研討，讓容器云安全未來的發(fā)展之路更加清晰。

?劉斌，清華大學(xué)工程管理碩士，中移信息云原生安全專家，信通院容器云原生安全規(guī)范主要編寫者之一，云安全聯(lián)盟（CSA）專家會員，曾在小佑科技擔(dān)任產(chǎn)品總監(jiān)。持有EXIN DevOps Master、PMP、CCSK、CISP、AWS SAP等各類認(rèn)證，在安全產(chǎn)品與解決方案有超過 10 年的探索和實(shí)踐。

汪照輝，中國銀河證券架構(gòu)師，專注于容器云、微服務(wù)、DevOps、數(shù)據(jù)治理、數(shù)字化轉(zhuǎn)型等領(lǐng)域，對相關(guān)技術(shù)有獨(dú)特的理解和見解。擅長于軟件規(guī)劃和設(shè)計，提出的“平臺融合”的觀點(diǎn)越來越得到認(rèn)同和事實(shí)證明。發(fā)表了眾多技術(shù)文章探討容器平臺建設(shè)、微服務(wù)技術(shù)、DevOps、數(shù)字化轉(zhuǎn)型、數(shù)據(jù)治理、中臺建設(shè)等內(nèi)容，受到了廣泛關(guān)注和肯定。?