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

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

容器云安全現狀

• 安全風險不容樂觀

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

早在2018年，某著名車企部署在AWS上的容器集群曾遭黑客植入挖礦木馬。2021年初，又有一家企業的Kubernetes集群遭攻擊團伙TeamTNT入侵并植入挖礦木馬。2021年4月1日，程序審計平臺Codecov遭攻擊，黑客利用Codecov的Docker鏡像創建過程中出現的錯誤，非法獲取腳本權限并對其進行修改，最后將信息發送到 Codecov 基礎架構之外的第三方服務器，影響數萬名客戶。

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

由此我們可以得出結論，不管是真實的網絡攻擊，還是攻防演練，亦或是合規檢查，容器云安全均處于重要位置，企業安全建設部門應當給予足夠重視。

• 標準規范不斷成熟

早期的容器云安全是缺少國內規范和標準的，廠商與用戶只能參考CIS的兩個Benchmark，包括K8S和Docker。但隨著需求旺盛，相關機構開始組織行業專家編寫相關規范，以指導相應的安全建設和產品研發。

• 2020年，信通院發布容器安全標準，并據此推出可信容器云認證；
• 2021年，信通院發布云原生架構安全白皮書；
• 2022年，CSA大中華區發布了云原生安全技術規范（CNST），同時聯合公安部第三研究所發布了針對云原生和云應用的安全可信認證。
• 2022 年，公安三所編寫等保2.0的容器云安全增補部分（征求意見稿）。

除此之外，各個行業或企業也在根據自身特點進行標準制定。

標準規范的推出和成熟，側面反映了其必要性和重要性，也為產品研發和用戶采購指明了方向，有較強的借鑒意義，降低了行業摸索走彎路的成本。容器云安全產品應該包括哪些功能，為用戶創造哪些價值變得相對比較明確。

• 各家產品競爭激烈

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

容器云安全產品探討

作為容器云安全細分領域的老兵，筆者曾見過多家廠商的容器云安全產品，也曾親自主導設計過某廠商的容器安全產品，后來又轉到某甲方客戶運營容器云安全。基于這幾年的個人經驗，用幾個話題拋磚引玉，供大家參考。

• 三大核心功能?

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

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

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

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

• 微隔離?

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

第一步：以業務應用為單位，對容器的網絡行為進行學習，構建網絡行為模型；

第二步：在構建完成模型后，對于偏離的流量進行告警；

第三步：運維人員對告警進行排查，確認是準確告警還是誤報。如果屬于誤報則對模型進行修正；如果是攻擊事件，則進行阻斷處置；

上述方案有兩個優點，一是沒有繁雜的配置，減少了運維人員的工作量；二是只產生告警不影響業務可用性。這個方案也存在挑戰和技術難度，構建的網絡行為模型如果不準確，有可能產生大量誤報，使得安全運營人員疲于應對，結果仍然會棄用此特性。

• 部署形態

容器云安全產品的部署形態，可以有四種選擇，主機Agent、平行容器、sidecar容器、無Agent。

國外的容器安全產品，例如Aqua、Twistlock、Stackrox、Neuvector，多采用平行容器的部署形態。國內的安全廠商，如果原來有主機安全產品，則傾向于在主機Agent上進行擴展，一個Agent同時負責主機安全與容器安全；如果是新創業的容器安全廠商，則傾向于采用平行容器的方式聚焦容器安全。

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

• 主機安全職責與容器安全職責歸屬不同部門；
• 已采購的主機安全產品不具備容器安全能力，迫使其必須單獨采購。

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

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

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

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

• 開源社區

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

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

容器云安全發展趨勢

隨著需求的持續增長，競爭的加劇，容器安全廠商需要繼續優化產品。用戶也會根據實際安全運營中的反饋，在容器云安全建設中進行調整。按照筆者的認知，無論是容器云安全產品，還是容器云安全建設，都有很大的進步空間。

• 深度發展?

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

未來，隨著越來越多人了解容器云安全，以及真實的增長的安全需求，會促使人們關注點回歸問題本質——是否能檢測和攔截大多數容器攻擊，保護容器云上的數據安全。要實現這一目標，并不意味著功能模塊的增加，而是比拼安全研發團隊的沉淀。

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

要實現更大的進展，當前大多數容器安全產品采用的用戶態進程檢測是存在不足的，也許內核態的ebpf技術能夠發揮作用，也許對“指令序列”的檢測能夠發現更細的問題，這都有待于進一步的調研和驗證。

• 廣度發展?

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

CNAPP的提出反映了整合的理念。對于用戶而言，使用統一的平臺，而非零散的煙囪式工具，可以有更完整的安全視角。但這個場景可能并非適用于所有用戶，因為有些用戶的研發測試環境與生產環境是網絡隔離的。用戶在建設容器安全時，可以結合自身實際情況，選擇合適的建設方案。

結束語

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

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

汪照輝，中國銀河證券架構師，專注于容器云、微服務、DevOps、數據治理、數字化轉型等領域，對相關技術有獨特的理解和見解。擅長于軟件規劃和設計，提出的“平臺融合”的觀點越來越得到認同和事實證明。發表了眾多技術文章探討容器平臺建設、微服務技術、DevOps、數字化轉型、數據治理、中臺建設等內容，受到了廣泛關注和肯定。?