最近測容器安全，才發現部署的容器云平臺和容器應用幾乎在裸奔，每個鏡像和容器都有各種各樣的漏洞，平臺本身也不少問題，真是不測不知道，一測嚇一跳。容器本身就是弱安全的，容易帶來越權逃逸等問題，同時容器應用研發人員對容器技術又缺乏了解，缺乏相應的安全意識和安全知識，這就帶來了比較嚴重的潛在的安全問題。

容器安全問題涉及內容很多，比如說鏡像安全、容器運行時安全(入侵檢測監控、入侵攔截和隔離)、容器平臺自身的安全、容器網絡安全、微隔離等，任何一項內容做好都不容易，而且又可能涉及多個部門和團隊，需要協作，所以我們也在討論容器安全應該由安全團隊來負責還是容器云平臺團隊來負責，在安全左移的趨勢下，是否應該更多關注pre-runtime安全等等。安全問題無處不在，有很多的事項迫在眉睫。

一、 容器安全的核心在哪?

最近的測試讓我一直在思考容器安全的核心到底應該在哪里。是鏡像安全?還是容器運行時安全?還是主機安全?網絡安全?雖然都在鼓吹安全左移，但我覺得容器運行時安全依然是核心，要能及時的檢測到安全威脅并自動實現入侵攔截，網絡微隔離或者網絡阻斷可能是最后的手段了。不過為了減少安全漏洞，降低安全威脅程度，前期的安全準備及安全措施也是至關重要，比如鏡像安全掃描和補丁修復，平臺和網絡自身的安全能力等等，都是密切相關。任何環節有漏洞，都可能會帶來嚴重的問題。

二、 安全左移

安全左移目的就是要提前采取措施修復潛在的漏洞，盡可能在后期的運行過程中增強抗攻擊能力。對于容器云平臺來說，基礎鏡像的維護就非常重要。雖然目前說可以很方便的從網絡上下載各種各樣的鏡像文件，但很多鏡像文件都存在這樣那樣的眾多漏洞，如果不加區分的部署在自己的容器云環境，勢必會帶來很多潛在的問題。所以這就需要在容器云平臺提供企業業務應用開發所需的基礎鏡像，比如jdk、tomcat、nginx、mysql、kafka、nodejs、CentOs等等，這些鏡像需要容器團隊來維護并及時的更新，在發現新的漏洞之后先更新基礎鏡像，然后在合適時間合適的方式用新鏡像更新存量運行時的容器。

基礎鏡像的安全維護可能是一個不小的工作量。但是這是一個值得做的事情。很多容器云廠商也提供像制品庫、應用商店一樣的功能來管理鏡像，但缺乏對鏡像的深度維護和安全舉措。這些鏡像往往存在著很多漏洞，在公司內網可能還好，一旦運行在互聯網環境，就面臨著極大的威脅。按照安全左移的思想，最好的辦法就是所有部署的鏡像都是安全的鏡像，在部署之前解決掉安全問題。在測試中我們震驚于一個鏡像竟然存在數百個高危漏洞，如果讓業務應用團隊去修復，基本上是不可能的。所有的業務應用鏡像最好來自于平臺所提供的安全的基礎鏡像。這樣，至少統一的安全的基礎鏡像會減少安全漏洞，也減少業務團隊自己下載、生成鏡像所帶來的安全隱患。

三、 Pre-Runtime鏡像掃描

提供安全的基礎鏡像應該是容器云平臺的基本職責之一。不過業務團隊還需要加載業務應用及相應的工具庫等到基礎鏡像，然后生成業務鏡像。這就可能引入新的安全威脅。在鏡像部署之前或者在鏡像進入鏡像倉庫之前需要進行必要的安全掃描，以檢測鏡像文件可能存在的漏洞和問題，在部署之前修復鏡像存在的漏洞。

我們在建設容器云平臺時，“以鏡像倉庫為媒介”，隔離開發和部署，我們不向終端用戶提供Docker和Kubernetes CLI命令，所有的操作通過平臺UI完成。也就是說要部署鏡像，需上傳鏡像到鏡像倉庫，上傳鏡像倉庫里的鏡像可以自動被安全掃描。如果存在高危漏洞，則可以通過設置的規則禁止部署。

我們測試的容器安全廠商提供Jenkins插件來實現高危漏洞鏡像阻斷部署，用于CD持續部署流程。由于思路的不同，實現方式有差別。不過我個人覺得可以再安全左移一點，把部署阻斷放在鏡像倉庫。高危漏洞的鏡像禁止出鏡像倉庫或者甚至禁止進鏡像倉庫，在upload時實現鏡像的安全掃描和高危阻斷。

四、 運行時安全檢測和監控

鏡像不被運行，即便有漏洞、有病毒也不會帶來危害，但一旦被運行生成容器，那么漏洞就是實實在在的，病毒就可能開始發作。所以容器啟動時的檢測是運行時檢測的第一步。這和操作系統自身的漏洞檢測、病毒檢測等是一樣的。所以我們測試的廠商所使用的安全引擎也幾乎一摸一樣，能力基本相同。目前檢測結果相對來說誤報的幾率還是很大的，對于一些高危的威脅定義也有差別。其實我們覺得高危應該是指某一個漏洞或病毒等的威脅危害程度，而不是指這個鏡像或容器的綜合威脅評判得分。用得分綜合評判容易導致誤解。個人覺得更應關注個體危害，當然也要關注綜合威脅。

容器運行起來，如果有漏洞就可能被攻擊，所以這就需要對容器網絡流量和網絡異常請求進行監控，對容器的整個運行時進行監測。這和傳統的網絡安全主機檢測是一樣，所以一家以傳統主機安全擴展到容器安全的廠商在這方面是占優勢的，至少理論上是占優勢的。不過容器網絡又區別于傳統網絡，容器網絡安全和容器網絡隔離措施也稍有別于傳統網絡安全。

五、 容器網絡安全和微隔離

容器網絡是一種虛擬化網絡SDN(軟件定義網絡)，可以自成一體。容器網絡安全隔離有幾種實現方式：零信任網絡微隔離、ServiceMesh、Kubernetes網絡策略等。零信任網絡就是通過軟件定義網絡來實現，所以如果要構建零信任體系，可以采用零信任網絡微隔離技術。不過由于當前實際的網絡環境，離零信任網絡還是有不小的距離，雖然希望引入零信任網絡微隔離能力，不過由于其要求有些高，難以落地而作罷。Kubernetes網絡策略隔離是最簡單的方式，各家廠商基本上也是采用這種方式，不過用網絡策略配置規則是非常的繁瑣，在容器量小的情況下還可以接受，大量時就非常復雜化。可能要分類、分域等，對于跨應用、跨域訪問的請求，眾多的規則很容易帶來混亂。在容器網絡安全提上日程的當前，ServiceMesh可能是一個比較好的選項。基于ServiceMesh實現流量鏈路拓撲，流量安全管控，訪問控制和容器網絡隔離等，配合網絡安全引擎，從而實現容器網絡的運行時安全和微隔離管控等。

六、 容器安全回歸容器平臺

不經過這次測試，對于容器安全廠商的本質差別其實是難以認知的。對于市面上的反饋，參加測試的兩家半斤八兩、功能大同小異，甚至廠商自身的人員也沒說明白有什么實質差別。

前面我們提到過，一家是從傳統主機安全擴展到容器安全，一家是云原生安全。首先從其產品理念和產品架構來說，就有很大的區別。主機安全廠商的容器安全產品是一個附屬組件，緊耦合于主機安全產品，至少目前是無法分離的，這就使其從容器云平臺視角看起來顯得笨重。不過從傳統網絡安全的視角來看則是完美的。云原生的容器安全產品架構則和容器云的輕量、敏捷很匹配，這是我比較喜歡的。關注點是不一樣的。所以一千個人眼里有一個前哈姆雷特，也是正常的。

不過容器安全最終還是要回歸容器云平臺的，容器安全運維核心在于容器云平臺，而不是網絡，這是有些區別的。特別如果不能很好的區分容器主機和非容器主機，會帶來額外的維護工作量。容器云平臺的容器安全我覺得可以看作是應用安全的一部分，雖然也涉及網絡安全，但核心不在網絡，所以容器安全回歸容器云平臺會更合適點。

當然，容器安全離不開網絡安全團隊的支持，畢竟很多問題都需要專業的網絡安全的協助和支持。

容器安全的市場取決于容器平臺的市場，所以最終容器安全的前景依賴于和容器云平臺的應用前景。如果把容器安全能力直接融合于容器云平臺，使容器安全能力融合成或至少集成容器平臺或容器云平臺的一部分，那就更完美了。