【摘 要】 本文對企業(yè)云原生架構(gòu)特點和云原生環(huán)境下容器、容器編排平臺、網(wǎng)絡以及微服務應用等方面面臨的安全風險進行了分析說明，給出了云原生環(huán)境下安全機制左移、容器運行時行為的聚焦、最小權(quán)限原則和零信任架構(gòu)的防護思路，并針對云原生風險，結(jié)合云原生防護思路提出了云原生全生命周期的安全防護解決方案。

【關(guān)鍵詞】 云原生 云安全 容器

1 引言

云計算的快速發(fā)展和業(yè)務系統(tǒng)快速迭代部署、可移植性、可擴展性等需求的不斷增長，促使容器化、服務網(wǎng)格、微服務、無服務等云原生（Cloud Native）技術(shù)得到企業(yè)的廣泛關(guān)注和應用。云原生應用的敏捷、高效、彈性擴展等特性在企業(yè)數(shù)字化轉(zhuǎn)型和降本增效、專注業(yè)務價值效率方面發(fā)揮著重大助力作用，但隨之而來的安全問題也日益突出，構(gòu)建全方位的云原生環(huán)境安全體系是企業(yè)“上云”的必經(jīng)之路。

2 云原生環(huán)境及面臨的安全挑戰(zhàn)和風險

大型企業(yè)從傳統(tǒng)的IT系統(tǒng)轉(zhuǎn)型升級為云原生應用系統(tǒng)往往按照不同的業(yè)務域，分類、分段、分層建設(shè)，應用架構(gòu)體系則從基礎(chǔ)設(shè)施架構(gòu)和業(yè)務能力架構(gòu)兩方面不斷抽象發(fā)展融合。一方面，下沉應用系統(tǒng)的全部基礎(chǔ)設(shè)施，將業(yè)務邏輯與基礎(chǔ)設(shè)施完全解耦，應用端聚焦業(yè)務創(chuàng)新和邏輯功能實現(xiàn)，基礎(chǔ)設(shè)施提供物理服務器到應用系統(tǒng)函數(shù)代碼之間的全部技術(shù)架構(gòu)和工具軟件，如容器、編排引擎、服務網(wǎng)格、無服務計算等。另一方面，開展業(yè)務邏輯能力的抽象設(shè)計，提取共性下沉至可復用的賦能平臺，形成小而精的業(yè)務靈活創(chuàng)新前臺和厚而廣的共性能力賦能中臺。

在基于“大中臺、小前臺”的平臺賦能支撐下，云原生的數(shù)字化環(huán)境可以很好地滿足各業(yè)務領(lǐng)域的功能復用與快速迭代、數(shù)據(jù)共享與互通、需求敏捷開發(fā)與高效交付、應用流水線部署與滾動升級、資源彈性擴展與實時在線以及運維自動化和智能化的要求。

云原生技術(shù)作為企業(yè)數(shù)字業(yè)務應用創(chuàng)新的原動力，在進入生產(chǎn)環(huán)境實現(xiàn)云原生應用全生命周期管理，發(fā)揮數(shù)字業(yè)務快速交付與迭代的優(yōu)勢過程中，也帶來了新的安全風險和挑戰(zhàn)。

云原生安全并不獨特，傳統(tǒng)IT環(huán)境下的安全問題在云環(huán)境下仍然存在，如DoS攻擊、內(nèi)部越權(quán)、漏洞攻擊、數(shù)據(jù)篡改、數(shù)據(jù)泄露等。同時，由云原生架構(gòu)的多租戶、虛擬化、快速彈性伸縮等特點和業(yè)務應用微服務化帶來的軟件架構(gòu)復雜度的大幅提升，內(nèi)部網(wǎng)絡流量、服務通信端口、容器等出現(xiàn)、消失的動態(tài)變化，業(yè)務微服務化后大量服務認證、訪問授權(quán)控制機制的自動配置管理，開發(fā)測試和生產(chǎn)環(huán)境中持續(xù)集成和持續(xù)交付自動化流水線的各環(huán)節(jié)的安全保護，以及未能及時跟上云原生技術(shù)快速發(fā)展而缺位的云原生安全策略和防護工具等問題，都使運行在云原生環(huán)境下的業(yè)務應用和數(shù)據(jù)面臨潛在安全風險。

與傳統(tǒng)安全技術(shù)相比，云原生安全技術(shù)表現(xiàn)出了明顯的不同，技術(shù)架構(gòu)由下至上可分為容器、虛擬化、宿主機運行時安全、編排平臺、服務網(wǎng)格安全、微服務、無服務安全，以及與開發(fā)運維過程相關(guān)的持續(xù)集成與持續(xù)部署（CI/CD）、開發(fā)運維一體化（DevOps）和運行過程的監(jiān)控、追蹤和測量等安全技術(shù)。簡而言之，傳統(tǒng)安全更重視邊界防護，而云原生安全更重視持續(xù)、動態(tài)和整體的安全防護。

2.1 容器環(huán)境的風險

容器技術(shù)是云原生技術(shù)體系的基石，容器是宿主機上的進程，其技術(shù)本質(zhì)是對宿主機操作系統(tǒng)的一層虛擬化，通過操作系統(tǒng)命名空間（Namespace）實現(xiàn)不同容器間主機名與域名、信號量/消息隊列和共享內(nèi)存、進程編號、網(wǎng)絡設(shè)備、網(wǎng)絡棧、端口、文件掛載點、用戶和用戶組環(huán)境的隔離；通過控制組（Cgroup）將容器進程或線程分隔到按資源劃分等級的不同組內(nèi)，實現(xiàn)對不同容器資源的使用限制。容器采用鏡像的方法創(chuàng)建，以虛擬化隔離和資源受限的方式運行在宿主機上，通過容器運行時接口（CRI）接受外部管理和調(diào)度。鏡像具有分層構(gòu)建、寫時復制、內(nèi)容尋址、聯(lián)合掛載等特征。

容器直接運行于宿主機操作系統(tǒng)之上，與以硬件層支持實現(xiàn)的虛擬化技術(shù)比較，更容易出現(xiàn)逃逸風險。攻擊者往往首先通過劫持容器內(nèi)部業(yè)務邏輯或直接控制等方式（如遠程攻擊、惡意容器、惡意租用），獲得容器內(nèi)某種權(quán)限下的命令執(zhí)行能力，之后借助技術(shù)手段進一步獲得該容器所在宿主機上某些權(quán)限的命令執(zhí)行能力并獲取相應資源。

例如，通過配置特權(quán)模式可使容器獲得與宿主機相同根權(quán)限（root）；通過掛載宿主機上運行的通信文件/var/run/docker.sock，在容器中安裝Docker客戶端可操作宿主機建立新容器；通過Docker程序漏洞（CVE-2019-5736）可在宿主機內(nèi)執(zhí)行攻擊載荷（payload）代碼；通過操作系統(tǒng)內(nèi)核漏洞（CVE-2016-5195）可進入宿主機root環(huán)境等。

因此，容器運行時的風險主要源于與宿主機操作系統(tǒng)共享了內(nèi)核和硬件資源，共享內(nèi)核相對于虛擬機（VM）而言具有更大的攻擊面。如果系統(tǒng)內(nèi)核存在漏洞或者使用者對容器有意無意地不當配置，其上運行的容器就存在被攻擊和隔離性被破壞的風險。一旦隔離性被打破，隨之而來的就是容器逃逸。

容器鏡像的風險同樣不容忽視，容器鏡像通過鏡像倉庫的自動化、層級化管理大大降低了容器使用的難度，開發(fā)者在方便使用的同時也要重視可能發(fā)生的安全問題。鏡像的風險一般來自于不可靠的鏡像來源，鏡像構(gòu)建時引入的不安全第三方組件，及包括官方鏡像在內(nèi)的鏡像自身存在的漏洞等。通常軟件項目中會使用大量開源軟件，按照以往的經(jīng)驗，官方提供下載的軟件一般是最新且安全可靠的。但2015年一份研究報告顯示，Docker公共倉庫（Docker Hub）中超過30%的官方鏡像包含高危漏洞，而2021年全年公開的通用漏洞披露（CVE）漏洞數(shù)為20139個，其中高危漏洞數(shù)高達4064個。漏洞鏡像主要集中在種類繁多的應用程序中間件的鏡像中。鏡像的風險必然導致容器運行的風險。

2.2 容器編排平臺的風險

云原生的焦點是業(yè)務服務，業(yè)務服務核心是對服務的管理和控制，如服務暴露、負載均衡、流量感知、應用擴容、灰度發(fā)布、應用更新等。服務編排提供了分布式的計算、存儲和網(wǎng)絡資源的管理功能，實現(xiàn)了按需、彈性地控制服務的位置、容量、版本，監(jiān)控并保證業(yè)務的可訪問性。

事實上，編排系統(tǒng)與容器之間并非完全獨立。以當前最流行的云原生管理與編排系統(tǒng)Kubernetes（K8s）為例，K8s集群本身的API服務管理器（API Server）、控制器（Controller Manager）、調(diào)度器（Scheduler）、基本域名解析服務器（CoreDNS）等服務端組件和K8s網(wǎng)絡代理（Kube-proxy）、K8s節(jié)點代理服務（Kubelet）等客戶端組件均以宿主機的一個或多個進程形式運行，而集群使用YAML語言以聲明形式創(chuàng)建的K8s最小部署單元（Pod）實際是同一網(wǎng)絡命名空間下的多個容器組成的邏輯組，因此K8s并不能降低由其管理的容器環(huán)境本身已存在的安全風險。另外，多節(jié)點組成的K8s集群使用第三方網(wǎng)絡插件提供節(jié)點間通信的機制，也使集群網(wǎng)絡的風險比單宿主機運行容器的網(wǎng)絡風險更大。

除此之外，K8s內(nèi)部核心組件如API Server設(shè)置了便于測試環(huán)境或者集群初啟動時使用的未加密端口8080，Kubelet和分布式鍵值對存儲系統(tǒng)（Etcd）可以通過改變啟動參數(shù)配置使用匿名訪問功能，以及用于集群訪問控制的認證、授權(quán)和準入機制設(shè)置過于寬松，高權(quán)限賬號濫用等配置、操作、管理性問題同樣威脅著云原生環(huán)境的安全，不安全的配置暴露于網(wǎng)絡中將給云安全帶來嚴重的風險。

2.3 云原生網(wǎng)絡的風險

不同于網(wǎng)絡位置有明確劃分、具有單一網(wǎng)絡連接關(guān)系的傳統(tǒng)IT應用，云原生應用采用網(wǎng)絡虛擬化的部署方式，實際上是對網(wǎng)絡邊界進行了重新定義。例如，Docker容器在網(wǎng)絡命名空間隔離下，一般通過虛擬以太網(wǎng)（Veth）設(shè)備對、網(wǎng)橋等虛擬設(shè)備采用動態(tài)地址映射方式與外界通信；K8s則以Pod為單位，Pod內(nèi)部的所有容器共享一個網(wǎng)絡堆棧，不同Pod之間以非網(wǎng)絡地址轉(zhuǎn)換（NAT）的方式互相通信，即“每個Pod分配一個IP（IP-per-Pod）”模型。從宏觀上看，集群中的網(wǎng)絡空間、包過濾防火墻（Iptables）和路由隨著容器的產(chǎn)生、消亡不斷動態(tài)變化，分布式容器集群網(wǎng)絡的復雜度大大提升，這必然會引入新的網(wǎng)絡風險。

每個容器雖然與宿主機之間存在隔離，但一般情況下同一宿主機上的容器位于同一局域網(wǎng)，網(wǎng)絡互通。如果攻擊者非法獲取局域網(wǎng)內(nèi)一個容器的權(quán)限，就有可能與其他容器非法通信，發(fā)生容器間的網(wǎng)絡攻擊（東西向攻擊）。

K8s實現(xiàn)了容器的分布式集群部署，集群Pod間可互相通信。在沒有其他網(wǎng)絡隔離策略和Pod安全策略的情況下，可能存在網(wǎng)絡探測、拒絕服務和中間人攻擊等網(wǎng)絡攻擊（南北向攻擊）。

2.4 云原生應用的風險

云原生應用采用微服務架構(gòu)、前后端分離的模式設(shè)計，交互方式從傳統(tǒng)的Web請求/響應轉(zhuǎn)向為各類API請求/響應，使用方式逐漸由“人-機交互”轉(zhuǎn)變?yōu)椤皺C-機交互”，通過表述性狀態(tài)轉(zhuǎn)移風格的超文本傳輸協(xié)議（RESTful/Http）、二進制/跨語言的遠程過程調(diào)用（gRPC）等方式進行通信，App服務的數(shù)量和API請求量大大增加。新模式在帶來高彈性、可擴展、可移植性優(yōu)勢的同時，也在安全方面有了新變化。

傳統(tǒng)的以Web為主的應用風險依然存在，如注入、跨站腳本、敏感數(shù)據(jù)泄露、使用有漏洞的第三方組件等。當傳統(tǒng)的單體應用拆分為多個服務后，前端的單一請求在后端可能有數(shù)以千計的服務調(diào)用關(guān)系，復雜的調(diào)用鏈和分布式問題更容易在外部訪問急劇增加時，大量占用甚至耗盡CPU資源，從而造成拒絕服務風險。

相較于作為一個整體對用戶進行授權(quán)、訪問單一的傳統(tǒng)IT應用，微服務應用的所有服務間需互相認證授權(quán)，請求來源除了用戶側(cè)外，還有大量內(nèi)部或其他服務API調(diào)用，其認證授權(quán)更為復雜。若某些API或微服務之間的鑒權(quán)或訪問權(quán)限配置錯誤，就有可能造成數(shù)據(jù)非法訪問、非法操作等問題。同時，應用的配置數(shù)量與服務數(shù)量成正比，微服務數(shù)量的增加導致各種服務、證書、數(shù)據(jù)訪問、環(huán)境變量等配置增加，且生產(chǎn)環(huán)境中要求實現(xiàn)的動態(tài)調(diào)整對服務的配置管理、密鑰管理也提出更高的要求。復雜度和管理難度的上升，增加了數(shù)據(jù)泄露風險。

3 云原生環(huán)境安全防護思路

3.1 安全機制左移

容器的生存時間（Time To Live，TTL）對安全技術(shù)有顯著的影響。據(jù)統(tǒng)計，46%的容器生存時間小于1小時，11%的容器小于1分鐘，對容器的攻擊和防護有可能跟不上容器自身的變化。因此，對于攻擊者而言，在其攻擊鏈條中會傾向于尋找更持久化的資源，如代碼、第三方庫、鏡像、倉庫、編排系統(tǒng)、控制面、宿主機等；而對于安全防護而言，將實時殺毒、入侵檢測等防護工具安裝在輕量級的容器當中變得不可行，需轉(zhuǎn)變思路將安全控制向開發(fā)側(cè)轉(zhuǎn)移，在DevOps中加入更多安全控制，包括開發(fā)/測試/驗證安全、軟件供應鏈安全、鏡像倉庫安全、監(jiān)控與分析以及配置和暴露面的核查。例如，使用代碼檢查工具進行代碼靜態(tài)分析、使用鏡像漏洞掃描工具對鏡像倉庫進行掃描、核查用戶憑證、密鑰配置等。開發(fā)及安全運維一體化（DevSecOps）框架如圖1所示。

3.2 容器運行時行為的聚焦

容器具有體量小、平均生命周期短、變化較快的特點，因其源于鏡像，在運行時來自同一鏡像的容器行為具有相似性，如容器的用戶、進程及數(shù)量、文件路徑、CPU/內(nèi)存資源使用等。通過對容器的行為畫像、分析和規(guī)格匹配，若出現(xiàn)異常的新用戶、新路徑、CPU偏高等情況，可以獲取高置信度的告警信息。

3.3 最小權(quán)限原則

在宿主機、容器、編排集群、DevOps以及微服務管理中，多種訪問關(guān)系錯綜復雜，用戶和服務認證授權(quán)方面錯誤配置和漏洞非常容易被利用。因此，要盡量明確組件間邊界和劃分，控制權(quán)限的細粒度，合理限制組件的權(quán)限，確保組件只執(zhí)行它被授權(quán)的行為，限制容器對基礎(chǔ)設(shè)施和同存的其他容器的干擾和影響，保證容器與其所在宿主機的隔離，避免攻擊者惡意越權(quán)訪問，使數(shù)據(jù)或功能遭到惡意破環(huán)。

3.4 零信任架構(gòu)

云原生環(huán)境下云計算、容器集群架構(gòu)復雜，訪問類型多樣，尤其在涉及多租戶，云的運營方、使用方、應用開發(fā)方均為獨立實體的情況下，客觀上要求能夠隨時在云原生環(huán)境的任何位置進行風險的控制、分析和防范，也就是零信任（默認不信任）架構(gòu)的理念需要貫穿在安全防護中。

4 云原生環(huán)境安全體系構(gòu)建方案

針對云原生環(huán)境下容器基礎(chǔ)設(shè)施、編排平臺、網(wǎng)絡、云原生應用層面存在的風險，結(jié)合云安全防護思路，在對應層面建立安全防護機制，形成全生命周期的安全防護體系，如圖2所示。

4.1 容器基礎(chǔ)設(shè)施的安全

在鏡像構(gòu)建時，驗證依賴鏡像的來源，最小化安裝減小風險引入，構(gòu)建完成立即進行漏洞掃描；在鏡像倉庫中，從公共倉庫選擇官方鏡像最新版本，下載后進行漏洞檢測并保證及時更新，私有倉庫配置安全證書，并對用戶訪問進行權(quán)限控制；在鏡像分發(fā)時，利用數(shù)字簽名對鏡像進行驗證，防止被惡意篡改。

從容器宿主機的角度，通過最小化安裝、最小權(quán)限授權(quán)、容器存儲單獨分區(qū)、Docker守護進程及相關(guān)文件目錄審計，Docker軟件及時更新等方式對容器環(huán)境進行加固。

充分利用Linux自身內(nèi)核安全機制來實現(xiàn)容器資源的隔離和權(quán)限的管控，如利用SELinux實現(xiàn)進程訪問文件的強制控制訪問，保證進程只能訪問它的任務中所需的文件。

監(jiān)測運行時容器異常行為，正常的容器進程行為雖然是動態(tài)的，但其行為應該在一定基線內(nèi)變化，可以認為大幅偏離此基線的行為存在風險。這種監(jiān)測基線既可以通過已知威脅的規(guī)則庫建立，也可以通過大量容器行為和屬性集合進行分類、聚合、自學習等方式來自動構(gòu)建。

4.2 編排系統(tǒng)的安全

利用K8s自身提供的安全機制，從認證授權(quán)、準入控制、密鑰管理以及Pod自身提供的安全策略和網(wǎng)絡策略確保編排系統(tǒng)的組件和配置都是符合安全要求的。

利用X.509證書開啟K8s的集群訪問認證，要求客戶端必須通過證書驗證后才能進一步授權(quán)；啟動服務賬號令牌認證機制，通過令牌控制集群內(nèi)進程能否與API Server進行通信；使用Secret對象保存敏感信息，如密碼、令牌和SSH密鑰；通過基于角色的訪問控制（RBAC）為Pod安全策略授權(quán)實現(xiàn)準入控制，以及通過網(wǎng)絡策略實現(xiàn)Pod間的可靠通信等。

4.3 網(wǎng)絡安全

針對云原生網(wǎng)絡架構(gòu)虛擬化、連接情況復雜、網(wǎng)絡邊界動態(tài)變化的特點，需要在更細粒度上實現(xiàn)網(wǎng)絡隔離，減少不同容器間網(wǎng)絡橫向攻擊的風險。同時，需要引入零信任安全理念。

目前比較先進的3層以上可進行網(wǎng)絡隔離的技術(shù)是微服務管理框架服務網(wǎng)格（Istio）下的邊車（Sidecar）模式，如圖3所示。Sidecar代理如邊緣/服務代理（Envoy）通過流量劫持接受控制面的調(diào)度，協(xié)調(diào)與其連接的服務實例的出入站通信，實現(xiàn)了更細粒度調(diào)整和控制端口、協(xié)議的功能，所有網(wǎng)格內(nèi)的Sidecar代理實例由控制平面的服務發(fā)現(xiàn)和流量管理組件（Pilot）管理和配置，流量控制較為容易且無需修改應用。

4.4 應用安全

在開發(fā)側(cè)引入安全機制，對軟件依賴的第三方庫進行安全性分析和漏洞掃描，及時告警，保證軟件供應鏈安全；在開發(fā)中加強安全檢查、漏洞測試和代碼審計，提升開發(fā)人員的安全意識和安全技術(shù)能力，減少早期漏洞引入。

引入云原生API網(wǎng)關(guān)，對所有的外部訪問進行流量接入、認證授權(quán)、監(jiān)控審計、傳輸層安全（TLS）加密等細粒度的控制。

引入服務網(wǎng)格治理，以Istio為主的安全機制，對微服務間的互訪采用開放的JWT標準認證、Istio授權(quán)、TLS雙向傳輸加密等方法進行安全防護。

針對無服務計算（FaaS）可能存在的風險，采用加強服務平臺自身的隔離和安全防護機制，開發(fā)的函數(shù)遵從安全規(guī)范，對無服務（Serverless）實例進行監(jiān)控審計，定期清理非必要Serverless來減小攻擊面等方法進行防護。

5 結(jié)語

隨著云計算技術(shù)的發(fā)展，云原生已是大勢所趨，新技術(shù)的不斷發(fā)展也必然會持續(xù)引入新的風險。云原生安全不僅僅是對已知安全問題的防護，更是對云原生環(huán)境中的所有安全風險的快速發(fā)現(xiàn)和響應。未來的云原生安全必然會發(fā)展出更多新的手段和工具，必然也會具備云原生的特點，如微服務、彈性擴展和自動化編排等。企業(yè)的“上云”之路必須轉(zhuǎn)變傳統(tǒng)應用安全的防護思路，重視云原生安全。

（原載于《保密科學技術(shù)》雜志2022年7月刊）