今天，云原生技術(shù)為企業(yè)帶來快速交付的優(yōu)勢之外,也帶來了新的安全要求與挑戰(zhàn)。一方面，新技術(shù)（容器、編排、DevOps、微服務(wù)）的引入帶來了新安全問題，如鏡像的供應(yīng)鏈問題、容器的逃逸問題、集群的橫向移動(dòng)問題、微服務(wù)的邊界問題等，需要引入新的安全防護(hù)手段；另一方面，云原生持續(xù)開發(fā)/集成的開發(fā)模式的轉(zhuǎn)變，傳統(tǒng)安全無法適配新的開發(fā)節(jié)奏和安全要求。

在長期跟蹤容器安全的研究之后，本文基于各類材料，重點(diǎn)對容器發(fā)展、容器鏡像安全、K8S發(fā)展的技術(shù)趨勢進(jìn)行整理分析，與各位業(yè)內(nèi)安全同仁分享，為守護(hù)云原生安全的發(fā)展貢獻(xiàn)一份力量。

1. 容器生態(tài)發(fā)展八大洞見

與傳統(tǒng)部署相比，安全專家和管理員在容器化環(huán)境中需要保護(hù)的組件更多、更復(fù)雜，涉及容器和底層基礎(chǔ)設(shè)施，需要將安全集成到開發(fā)管道中，才能確保所有組件從最初的開發(fā)階段到其生命周期結(jié)束都受到保護(hù)。

洞見1：超過一半的組織運(yùn)行容器數(shù)量大于250個(gè)，有6%的人管理超過5,000個(gè)容器（如圖1所示）。這表明越來越多的工作負(fù)載正在轉(zhuǎn)向容器并遠(yuǎn)離傳統(tǒng)架構(gòu)。

圖1 運(yùn)行容器的數(shù)量

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

圖2 每個(gè)主機(jī)上容器數(shù)量中值

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

圖3 容器的生命周期

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

圖4 容器運(yùn)行時(shí)

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

圖5 容器鏡像倉庫

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

圖6 容器容量規(guī)劃

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

圖7 容器開源軟件

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

圖8 容器化服務(wù)周期

2. 容器鏡像安全態(tài)勢八大洞見

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

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

圖9 以 root 身份運(yùn)行的容器

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

圖10 鏡像倉庫拉?。ü袀}庫vs私有倉庫）

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

圖11 基本鏡像操作系統(tǒng)

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

圖12 容器鏡像生命周期

洞見5：在容器工作負(fù)載中，在62%容器中檢測到shell，38%檢測到使用敏感掛載點(diǎn)啟動(dòng)的容器（如圖13所示），這意味著該容器能夠更改主機(jī)系統(tǒng)上的重要文件。

圖13 容器運(yùn)行時(shí)安全警報(bào)

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

圖14 掃描鏡像的位置

洞見7：在生產(chǎn)環(huán)境中，運(yùn)行的85%的鏡像至少包含一個(gè)可修補(bǔ)漏洞。此外，75%的鏡像包含“高”或“嚴(yán)重”的可修補(bǔ)漏洞（如圖15所示）。

圖15 運(yùn)行時(shí)可修補(bǔ)漏洞

洞見8：在關(guān)注告警中，Kubernetes.node.ready仍然是最常用的，其次是CPU使用率和正常運(yùn)行時(shí)間指標(biāo)（如圖16所示）。

圖16 Top10警報(bào)

3. K8S安全發(fā)展八大洞見

Kubernetes在組織中的使用越來越成熟，它是一個(gè)復(fù)雜的平臺(tái)，需要大量的配置和管理。為了保證Kubernetes工作負(fù)載的安全，需要通過實(shí)施安全措施來解決關(guān)鍵的架構(gòu)漏洞和平臺(tái)依賴。

Pod是Kubernetes中最小的部署單元，由一個(gè)或多個(gè)容器組成。Pod通常是網(wǎng)絡(luò)攻擊者在進(jìn)行容器漏洞利用時(shí)的初始執(zhí)行環(huán)境。鑒于此，我們應(yīng)該加固Pod安全，讓網(wǎng)絡(luò)攻擊者難以進(jìn)行漏洞利用，并限制入侵所造成的影響范圍。

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

圖17 編排工具

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

圖18 每個(gè)組織的 Pod 數(shù)量

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

圖19 集群數(shù)量和每個(gè)集群的節(jié)點(diǎn)數(shù)

洞見4：每個(gè)集群的Pod數(shù)量顯著增加，54%的組織在每個(gè)集群中運(yùn)行100多個(gè)Pod（如圖20所示）。每個(gè)節(jié)點(diǎn)的平均Pod數(shù)量有所下降，這表明團(tuán)隊(duì)正在部署更多更小的節(jié)點(diǎn)來處理他們的工作負(fù)載。

圖20 集群Pod數(shù)和節(jié)點(diǎn)Pod數(shù)

洞見5：Kubernetes組織每臺(tái)主機(jī)運(yùn)行16個(gè)Pod，而使用ECS的組織每臺(tái)主機(jī)運(yùn)行5個(gè)任務(wù)。2020-2021年，這兩種環(huán)境的數(shù)字保持一致，這表明組織正在尋找合適數(shù)量的Pod和任務(wù)來支持他們的應(yīng)用程序。我們還發(fā)現(xiàn)Kubernetes Pod和ECS任務(wù)平均運(yùn)行1.5個(gè)容器（如圖21所示）。

圖21 每個(gè)環(huán)境的主機(jī)密度

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

圖22 Kubernetes自動(dòng)擴(kuò)展使用量的時(shí)間變化

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

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

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

圖24 指標(biāo)類型的平均使用情況?