今天，云原生技術為企業帶來快速交付的優勢之外,也帶來了新的安全要求與挑戰。一方面，新技術（容器、編排、DevOps、微服務）的引入帶來了新安全問題，如鏡像的供應鏈問題、容器的逃逸問題、集群的橫向移動問題、微服務的邊界問題等，需要引入新的安全防護手段；另一方面，云原生持續開發/集成的開發模式的轉變，傳統安全無法適配新的開發節奏和安全要求。

在長期跟蹤容器安全的研究之后，本文基于各類材料，重點對容器發展、容器鏡像安全、K8S發展的技術趨勢進行整理分析，與各位業內安全同仁分享，為守護云原生安全的發展貢獻一份力量。

1. 容器生態發展八大洞見

與傳統部署相比，安全專家和管理員在容器化環境中需要保護的組件更多、更復雜，涉及容器和底層基礎設施，需要將安全集成到開發管道中，才能確保所有組件從最初的開發階段到其生命周期結束都受到保護。

洞見1：超過一半的組織運行容器數量大于250個，有6%的人管理超過5,000個容器（如圖1所示）。這表明越來越多的工作負載正在轉向容器并遠離傳統架構。

圖1 運行容器的數量

洞見2：每臺主機上容器數量中位數都有所增加，2020年同比增長了33%，2021年同比增長12%，達到了46個（如圖2所示），許多組織正受益于硬件資源利用率的提高。

圖2 每個主機上容器數量中值

洞見3：大約44%容器存活時間不到五分鐘（如圖3所示），許多容器只需要足夠長的時間來執行一個函數，幾秒鐘可能看起來很短，但對于某些流程來說已足夠。這表明容器的短暫性仍然是該技術的獨特優勢之一，但也帶來了新的挑戰，包括監控、安全性和合規性等新問題。

圖3 容器的生命周期

洞見4：在容器運行時使用上，Docker采用占46%，首次跌破50%，但Docker仍然是組織中使用最多的容器運行時（如圖4所示）。

圖4 容器運行時

洞見5：在容器倉庫的使用上，Quay首次超過Docker，占客戶采用率的26%（如圖5所示）。

圖5 容器鏡像倉庫

洞見6：在資源使用限制上，60%的容器沒有定義CPU限制，51%沒有定義內存限制。即使在有CPU限制的集群中，平均有34%的CPU內核未被使用（如圖6所示）。

圖6 容器容量規劃

洞見7：在開源軟件使用上，基于容器的應用開發中，使用前12種開源技術（如圖7所示），排名前三是NGINX、GO和JMX。

圖7 容器開源軟件

洞見8：容器化服務正在不斷改進（如圖8所示），使用壽命保持相對穩定，其中31%服務周期超過2周。

圖8 容器化服務周期

2. 容器鏡像安全態勢八大洞見

隨著組織將更多的容器工作負載轉移到生產中，我們看到需要將安全性和合規性集成到DevOps工作流程中。容器鏡像在容器安全中起著至關重要的作用。從鏡像創建的任何容器都會繼承其所有特征，包括安全漏洞、錯誤配置，甚至惡意軟件。

洞見1：76%的鏡像最終以root身份運行（如圖9所示）。

圖9 以 root 身份運行的容器

洞見2：公共鏡像倉庫越來越受到信任，從2020年的47%增加到2021年的61%（如圖10所示）。

圖10 鏡像倉庫拉取（公有倉庫vs私有倉庫）

洞見3：RHEL是迄今為止最受歡迎的基礎鏡像，占使用基礎鏡像的36%，只有25%的人使用Alpine（如圖11所示）。通過使用像Alpine這樣的精簡基礎鏡像，可以減少容器的攻擊面。

圖11 基本鏡像操作系統

洞見4：鏡像生命周期數據反映了代碼發布之間的時間變化（如圖12所示），大約一半的容器鏡像在一周或更短的時間內被替換。

圖12 容器鏡像生命周期

洞見5：在容器工作負載中，在62%容器中檢測到shell，38%檢測到使用敏感掛載點啟動的容器（如圖13所示），這意味著該容器能夠更改主機系統上的重要文件。

圖13 容器運行時安全警報

洞見6：52%的鏡像是在運行時掃描的，42%是在CI/CD管道中進行最初掃描的（如圖14所示）。青藤建議在鏡像生產、分發、運行階段都需要不斷重新掃描所有容器，以發現任何新披露的漏洞。

圖14 掃描鏡像的位置

洞見7：在生產環境中，運行的85%的鏡像至少包含一個可修補漏洞。此外，75%的鏡像包含“高”或“嚴重”的可修補漏洞（如圖15所示）。

圖15 運行時可修補漏洞

洞見8：在關注告警中，Kubernetes.node.ready仍然是最常用的，其次是CPU使用率和正常運行時間指標（如圖16所示）。

圖16 Top10警報

3. K8S安全發展八大洞見

Kubernetes在組織中的使用越來越成熟，它是一個復雜的平臺，需要大量的配置和管理。為了保證Kubernetes工作負載的安全，需要通過實施安全措施來解決關鍵的架構漏洞和平臺依賴。

Pod是Kubernetes中最小的部署單元，由一個或多個容器組成。Pod通常是網絡攻擊者在進行容器漏洞利用時的初始執行環境。鑒于此，我們應該加固Pod安全，讓網絡攻擊者難以進行漏洞利用，并限制入侵所造成的影響范圍。

洞見1：在編排工具的使用上，Kubernetes成為了絕對主流，K8S的使用率高達96%（如圖17所示）。

圖17 編排工具

洞見2：在過去兩年中，每個組織的平均Pod數量翻了一番（如圖18所示），Kubernetes主機的平均數量也出現了類似的相對增長。

圖18 每個組織的 Pod 數量

洞見3：整體上來看，大部分用戶的集群數量比較少，49%只有1個集群，此外每個集群的節點數量相對較少，大部分都只有1-5個Nodes，這表明許多企業仍處于早期使用Kubernetes的階段（如圖19所示）。未來企業會向更多集群和每個集群更多節點的方向轉變。

圖19 集群數量和每個集群的節點數

洞見4：每個集群的Pod數量顯著增加，54%的組織在每個集群中運行100多個Pod（如圖20所示）。每個節點的平均Pod數量有所下降，這表明團隊正在部署更多更小的節點來處理他們的工作負載。

圖20 集群Pod數和節點Pod數

洞見5：Kubernetes組織每臺主機運行16個Pod，而使用ECS的組織每臺主機運行5個任務。2020-2021年，這兩種環境的數字保持一致，這表明組織正在尋找合適數量的Pod和任務來支持他們的應用程序。我們還發現Kubernetes Pod和ECS任務平均運行1.5個容器（如圖21所示）。

圖21 每個環境的主機密度

洞見6：Kubernetes可以根據指標自動水平或垂直擴展Pod，以構建高可用性和高性能的容器應用程序。橫向擴展Pod的總數可確保應用程序能夠支持需求波動，而垂直擴展單個Pod的CPU和內存有助于管理應用程序的整體性能和成本。大約40%的Kubernetes組織使用HPA（橫向擴展），而使用VPA（垂直擴展）的組織不到1%（如圖22所示）。

圖22 Kubernetes自動擴展使用量的時間變化

洞見7：組織平均使用13個StatefulSet和28個PVC（Persistent Volume Claim）（如圖23所示），這表明越來越依賴Kubernetes來支持包括有狀態應用程序在內的各種工作負載。

圖23 Kubernetes Stateful Sets 和PVC的使用情況

洞見8：Prometheus廣泛用于Kubernetes、OpenShift和Istio等項目的度量標準。在JMX、StatsD和Prometheus這三個主流解決方案中，Prometheus連續第三年獲得收益。與去年同期相比，Prometheus指標的使用率從去年的62%增加到83%。隨著新編程框架的使用范圍擴大，JMX指標（用于Java應用程序）和StatsD等替代方案繼續下降，今年JMX急劇下降至僅4%，而去年為19%（如圖24所示）。

圖24 指標類型的平均使用情況?