云原生環境下的安全風險及防護策略研究

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

【關鍵詞】 云原生 云安全 容器

1 引言

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

2 云原生環境及面臨的安全挑戰和風險

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

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

云原生技術作為企業數字業務應用創新的原動力，在進入生產環境實現云原生應用全生命周期管理，發揮數字業務快速交付與迭代的優勢過程中，也帶來了新的安全風險和挑戰。

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

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

2.1 容器環境的風險

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

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

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

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

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

2.2 容器編排平臺的風險

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

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

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

2.3 云原生網絡的風險

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

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

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

2.4 云原生應用的風險

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

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

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

3 云原生環境安全防護思路

3.1 安全機制左移

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

3.2 容器運行時行為的聚焦

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

3.3 最小權限原則

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

3.4 零信任架構

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

4 云原生環境安全體系構建方案

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

4.1 容器基礎設施的安全

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

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

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

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

4.2 編排系統的安全

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

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

4.3 網絡安全

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

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

4.4 應用安全

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

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

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

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

5 結語

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

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