「裸奔」的容器，安全問題迫在眉睫
汪照辉 twt企业IT社区
【摘要】容器本身就是弱安全的，容易帶來越權逃逸等問題，同時容器應用研發人員對容器技術又缺乏了解，缺乏相應的安全意識和安全知識，這就帶來了比較嚴重的潛在的安全 問題，有很多的事項迫在眉睫。
【作者】汪照輝，中國銀河證券架構師，專注於容器雲、微服務、DevOps、資料治理、數位轉型等領域，對相關技術有獨特的理解與見解。 擅長於軟體規劃和設計，提出的「平台融合」的觀點越來越被認同和事實證明。 發表了許多技術文章探討容器平台建置、微服務技術、DevOps、數位轉型、資料治理、中台建置等內容，受到了廣泛關注與肯定。
最近測容器安全，才發現部署的容器雲平台和容器應用幾乎在裸奔，每個鏡像和容器都有各種各樣的漏洞，平臺本身也不少問題，真是不測不知道，一測嚇一跳 。 容器本身就是弱安全的，容易帶來越權逃逸等問題，同時容器應用研發人員對容器技術又缺乏了解，缺乏相應的安全意識和安全知識，這就帶來了比較嚴重的潛在的安全問題。
容器安全問題涉及內容很多，比如說鏡像安全、容器運行時安全（入侵偵測監控、入侵攔截和隔離）、容器平臺本身的安全、容器網路安全、微隔離等，任何一項內容做好都不容易 ，而且可能涉及多個部門和團隊，需要協作，所以我們也在討論容器安全應該由安全團隊來負責還是容器雲平台團隊來負責，在安全左移的趨勢下，是否應該更多關注pre- runtime安全性等等。 安全問題無所不在，有很多的事項迫在眉睫。
一、 容器安全的核心在哪？
最近的測試讓我一直在思考容器安全的核心到底該在哪裡。 是鏡像安全？ 還是容器運作時安全？ 還是主機安全？ 網路安全？ 雖然都在鼓吹安全左移，但我覺得容器運行時安全依然是核心，要能及時的檢測到安全威脅並自動實現入侵攔截，網絡微隔離或者網絡阻斷可能是最後的手段了。 不過為了減少安全漏洞，降低安全威脅程度，前期的安全準備及安全措施也是至關重要，例如鏡像安全掃描和修補程式修復，平台和網路本身的安全能力等等，都是密切相關。 任何環節都有漏洞，都可能帶來嚴重的問題。
二、 安全左移
安全左移目的就是要提前採取措施修復潛在的漏洞，盡可能在後期的運作過程中增強抗攻擊能力。 對於容器雲端平台來說，基礎鏡像的維護就非常重要。 雖然目前說可以很方便的從網路上下載各種各樣的鏡像文件，但許多鏡像文件都存在這樣那樣的眾多漏洞，如果不加區分的部署在自己的容器雲環境，勢必會帶來很多潛在 的問題。 所以這就需要在容器雲平台提供企業業務應用開發所需的基礎鏡像，例如jdk、tomcat、nginx、mysql、kafka、nodejs、CentOs等等，這些鏡像需要容器團隊來維護並及時的更新，在發現 新的漏洞之後先更新基礎鏡像，然後在適當時間適當的方式用新鏡像更新存量運行時的容器。
基礎鏡像的安全維護可能是一個不小的工作量。 但是這是一個值得做的事情。 許多容器雲廠商也提供像製品庫、應用程式商店一樣的功能來管理鏡像，但缺乏對鏡像的深度維護和安全措施。 這些鏡像往往存在著許多漏洞，在公司內部網路可能還好，一旦運作在網路環境，就面臨極大的威脅。 依照安全左移的思想，最好的方法就是所有部署的鏡像都是安全的鏡像，在部署前解決掉安全問題。 在測試中我們震驚於一個鏡像竟然存在數百個高風險漏洞，如果讓業務應用團隊去修復，基本上是不可能的。 所有的業務應用鏡像最好來自於平台所提供的安全的基礎鏡像。 這樣，至少統一的安全的基礎鏡像會減少安全漏洞，也減少業務團隊自行下載、產生鏡像所帶來的安全隱患。
三、 Pre-Runtime鏡像掃描
提供安全的基礎鏡像應該是容器雲端平台的基本職責之一。 不過業務團隊也需要載入業務應用程式及對應的工具庫等到基礎鏡像，然後產生業務鏡像。 這就可能引入新的安全威脅。 在鏡像部署之前或在鏡像進入鏡像倉庫之前需要進行必要的安全掃描，以偵測鏡像檔案可能存在的漏洞和問題，在部署之前修復鏡像存在的漏洞。
我們在建造容器雲端平台時，“以鏡像倉庫為媒介”，隔離開發和部署，我們不向終端用戶提供Docker和Kubernetes CLI命令，所有的操作都透過平台UI完成。 也就是說要部署鏡像，需上傳鏡像到鏡像倉庫，上傳鏡像倉庫裡的鏡像可以自動被安全掃描。 如果存在高風險漏洞，則可以透過設定的規則禁止部署。
我們測試的容器安全廠商提供Jenkins外掛程式來實現高風險漏洞鏡像阻斷部署，用於CD持續部署流程。 由於思路的不同，實作方式有差別。 不過我個人覺得可以再安全左移一點，把部署阻斷放在鏡像倉庫。 高風險漏洞的鏡像禁止出鏡像倉庫或甚至禁止進鏡像倉庫，在upload時實現鏡像的安全掃描和高危險阻斷。
四、 運行時安全偵測與監控
鏡像不會被運行，即使有漏洞、有病毒也不會帶來危害，但一旦被運行生成容器，那麼漏洞就是實實在在的，病毒就可能開始發作。 所以容器啟動時的檢測是運行時檢測的第一步。 這和作業系統本身的漏洞偵測、病毒偵測等是一樣的。 所以我們測試的廠商所使用的安全引擎也幾乎一摸一樣，能力基本上相同。 目前偵測結果相對來說誤報的幾率還是很大的，對於一些高風險的威脅定義也有差異。 其實我們覺得高危險應該是指某一個漏洞或病毒等的威脅危害程度，而不是指這個鏡像或容器的綜合威脅評判分數。 用得分綜合評判容易導致誤解。 個人覺得更應關注個體危害，當然也要關注綜合威脅。
容器運作起來，如果有漏洞就可能被攻擊，所以這就需要對容器網路流量和網路異常請求進行監控，對容器的整個運作時進行監測。 這和傳統的網路安全主機偵測是一樣，所以一家以傳統主機安全擴展到容器安全的廠商在這方面是佔優勢的，至少理論上是佔優勢的。 不過容器網路又有別於傳統網絡，容器網路安全和容器網路隔離措施也稍有別於傳統網路安全。
五、 容器網路安全與微隔離
容器網路是一種虛擬化網路SDN（軟體定義網路），可以自成一體。 容器網路安全隔離有幾種實作方式：零信任網路微隔離、ServiceMesh、Kubernetes網路策略等。 零信任網路就是透過軟體定義網路來實現，所以如果要建構零信任體系，可以採用零信任網路微隔離技術。 不過由於目前實際的網路環境，離零信任網路還是有不小的距離，雖然希望引入零信任網路微隔離能力，不過由於其要求有些高，難以落地而作罷。 Kubernetes網路策略隔離是最簡單的方式，各廠商基本上也是採用這種方式，不過用網路策略配置規則是非常的繁瑣，在容器量小的情況下還可以接受，大量時就非常複雜化。 可能要分類、分域等，對於跨應用程式、跨網域存取的請求，眾多的規則很容易帶來混亂。 在容器網路安全性提上行程的目前，ServiceMesh可能是比較好的選項。 基於ServiceMesh實現流量鏈路拓撲，流量安全管控，存取控制和容器網路隔離等，配合網路安全引擎，從而實現容器網路的運行時安全和微隔離管控等。
六、 容器安全回歸容器平台
不經過這次測試，對於容器安全廠商的本質差異其實是難以認知的。 對於市面上的回饋，參加測試的兩家半斤八兩、功能大同小異，甚至廠商本身的人員也沒說明白有什麼實質差別。
前面我們提到過，一家是從傳統主機安全擴展到容器安全，一家是雲端原生安全。 首先從其產品理念和產品架構來說，就有很大的差別。 主機安全廠商的容器安全產品是一個附屬組件，緊密耦合於主機安全產品，至少目前是無法分離的，這就使其從容器雲平台視角看起來顯得笨重。 不過從傳統網路安全的視角來看則是完美的。 雲端原生的容器安全產品架構則和容器雲的輕量、敏捷很匹配，這是我比較喜歡的。 關注點是不一樣的。 所以一千個人眼裡有一個前哈姆雷特，也是正常的。
不過容器安全最終還是要回歸容器雲平台的，容器安全運維核心在於容器雲平台，而不是網絡，這是有些差別的。 特別如果不能很好的區分容器主機和非容器主機，會帶來額外的維護工作量。 容器雲平台的容器安全我覺得可以看作是應用安全的一部分，雖然也涉及網絡安全，但核心不在網絡，所以容器安全回歸容器雲平台會更合適點。
當然，容器安全離不開網路安全團隊的支持，畢竟許多問題都需要專業的網路安全的協助與支持。
容器安全的市場取決於容器平台的市場，所以最終容器安全的前景依賴和容器雲端平台的應用前景。 如果把容器安全能力直接融合於容器雲平台，使容器安全能力融合成或至少整合容器平台或容器雲平台的一部分，那就更完美了。
Comments
Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!