云原生技術以其高效穩定、快速響應的特點不斷驅動著企業的業務發展，已成為目前企業數字業務應用創新的核心動力。但與此同時，云原生環境中的各類安全風險也在日漸增加，越來越多的企業也開始探索云原生環境中的安全架構設計方案。

在不久前由51CTO內容中心策劃推出的【T·TALK】系列活動第八期中，我們特別邀請到了小佑科技技術總監白黎明，進行了《云原生安全架構設計最佳實踐》的主題分享。重點介紹了云原生的發展趨勢、安全風險、安全架構設計等內容。【T·TALK】也將這期分享的精彩內容進行了整理，希望能為諸君帶來一些啟發。

?

云原生發展趨勢

2013年Pivotal公司首次提出了云原生概念。而在2015年時，Pivotal公司在其所撰寫的書中第一次正式定義了云原生的五個因素：

• 符合云原生應用12因素
• 面向微服務架構
• 自服務敏捷架構
• 基于API的協作
• 具有抗脆弱性

能滿足以上五個特性就屬于云原生應用。

2015年云原生計算基金會（CNCF）成立，CNCF在成立之初便對云原生進行了定義：

• 應用容器化
• 面向微服務架構
• 應用支持容器的編排調度

只要滿足以上三個方向的特性，就屬于云原生的應用。

2018年，隨著云原生技術的發展，CNCF根據最新的云原生基礎架構設施，重新對云原生進行了定義：

• 容器化
• 服務網格
• 微服務
• 不可變的基礎設施
• 聲明式的API

只要滿足以上五個方向的特性就屬于云原生應用了。

隨著云原生技術的不斷變化，容器化使操作系統的功能與特性進一步精簡。為滿足云原生定義中不可變基礎設施的條件，云原生操作系統應運而生。其特點是高度精簡的內核，只保留容器相關的依賴庫，使用容器客戶端作為包管理器。

云原生操作系統的共同理念，是所有進程必須運行在容器中。操作系統的宿主機上不能安裝任何應用程序，保證操作系統是完全不可變的，這就是所謂不可變的基礎設施，也是操作系統未來的發展趨勢。

早期的基礎架構是運行在物理機上的，而后隨著基礎設施的變化，應用開始運行在虛擬機之中。到了容器時代，所有的應用都運行在容器之中。在最新的流行趨勢里，目前國內外也有一些云廠商在提供對應的基礎設施架構——Serverless無服務器技術。

在物理機時代，基礎設施通常以年為運算單位的，當物理機上架到機房后，其會以一年或者五年作為生命周期下架。隨后的虛擬機則是以月作為其運算單位。到了容器時代，每次更新都需要重新構建新的容器，因此容器的生命周期是以天為單位的。而在無服務器時代，函數虛擬化則會以分鐘為單位。

容器化出現后，容器技術標準化的進程得到了加速。DevOps與容器相輔相成，應用容器平臺，就需要演變成為DevOps開發模式以加速發布流程。容器化的便捷推廣了DevOps，而容器又依賴DevOps來加快迭代速度，這是目前開發模式的演變趨勢。

當以容器為單位時，云原生、服務則為網絡邊界。在云原生領域中，并沒有IP的概念，所有云原生中的IP都是動態的，我們無法在傳統的防火墻上配置對應的IP地址。在云原生之中，容器的服務每天都會更新，每次更新IP地址都會是一個新的IP地址，原先配置的網絡策略均會失效。

物理機時代，物理機上架比較困難，因此通常會在一個物理機上跑多個應用。而虛擬機時代，為了提高服務的可用性，則通常會將單個服務拆分到單個虛擬機之上。再到現在，隨著服務接口越來越多，越來越依賴于微服務化，則需要將接口演變成微服務架構。

以微博為例，當出現熱點事件時，物理機與虛擬機都需要以小時為單位的較長時間構建才能夠實現業務恢復。而在容器化的場景下，容器啟動以秒級為單位，啟動速度遠快于物理機與虛擬機場景。因此在微博演進為容器架構后，已經很少再會因熱點事件而發生崩潰了。當然這其中上K8S平臺的自愈能力與動態擴縮容也功不可沒。

早期容器運行時使用Docker，因此當時通常將容器與Docker劃等號。容器自身分四個模塊，Docker也分為四個接口。但由于Docker是一整套開發套件，而K8S在運行時，只會用到runtime側。因此在運行效率的需求下，K8S在1.20版本時，已逐漸不再對Docker Shim進行支持，而是直接使用了Docker Containerd。

無論Containerd還是Docker，其對安全能力的支持的功能都并不十分完善。而Cri-o技術則可以滿足相對安全的需求，無需守護進程，每一個Cri-o的進程都可以擁有一個獨立的進程，父進程和子進程，去進行服務地運行。未來容器領域的趨勢，是底層基礎設施安全，包括安全的技術容器化。

?

云原生安全風險

目前，云原生領域需要考慮的安全問題主要有以下五個：

• 鏡像安全
• 鏡像倉庫安全
• 集群組件安全
• 容器網絡風險
• 微服務風險

其中鏡像安全風險是比較廣泛的。相較于基礎設施安全，云原生領域更加關注性能優化與基礎設施容器化。這也導致目前DockerHub鏡像之中，51%存在高危漏洞、80%存在中低危漏洞。而在企業構建鏡像時，90%的情況下，都需要從DockerHub上下載鏡像。

鏡像倉庫方面，企業不可能將所有的研發的鏡像、業務鏡像上傳到一個公開的鏡像倉庫中，源代碼需要存放在企業倉庫。但企業倉庫也同樣會存在安全漏洞的，這些漏洞被黑客利用后，會直接導致倉庫中的鏡像被替換。當從節點上去拉鏡像的時候，拉同一個鏡像可能拉到的是黑客帶有木馬病毒的鏡像，這也是非常危險的。

關于集群組件的風險，目前Docker自身存在111個漏洞、K8S存在65個漏洞、Open Shift存在35個漏洞，其他容器運行時例如Cri-o、Containerd與Kata Container，一共包含45個漏洞。集群組件漏洞相對較少，但也是同樣存在的。

當黑客通過上述漏洞入侵到集群中后，會繼續訪問其他集群內容器。物理防火墻，只能防護集群外流量，集群內的流量K8S有overlay與underlay兩種網絡架構。但無論是overlay還是underlay，傳統防火墻都無法防護集群內的攻擊情況，這便是集群內的網絡風險。

業務鏡像有漏洞還有可能引發另外一個問題，內置式鏡像組件漏洞。若開發人員所引用的API或使用的一些開發框架存在漏洞，那么當開發人員將開發組件打包到鏡像中時，就會出現這類問題。此前影響甚廣的Spring框架0 day漏洞，便是因為基礎設施漏洞，影響了國內近90%的企業。這類風險通常是研發所引入的，也就是微服務的風險。

云原生安全架構設計

以前的基礎設施，主要由防火墻與物理安全進行維護。而容器的計算環境方面，容器運行時安全、鏡像安全，需要專業的容器安全進行防護。容器的應用安全，則需要對應的容器安全進行微服務發現與Serverless防護。

云原生場景下，需要把研發安全體系納入云原生安全領域之中。這與傳統安全有所不同。研發人員必須參與到安全的建設體系之中，在研發過程中時刻關注云原生的數據安全，以及一些安全管理的權限。

在小佑目前的容器安全中有非常多的內置策略與機器行為學習策略、處置策略與事件。其中一個特點功能便是編排文件審計。可以直接對接到開發人員的代碼倉庫之中，從代碼倉庫中讀取代碼倉庫已存在的所有的Dockerfile文件、Yaml文件、編排文件。并通過Dockerfile文件推斷語法，以發現命令中所存在的問題。

審計完成后，若存在問題，則報告研發人員，并禁止構建鏡像。若無安全問題，則直接進行修改反饋，待修改完成后生成鏡像。此時還會將鏡像逆向為Dockerfile，并對鏡像與Dockerfile文件進行對比，若發現Dockerfile文件存在篡改，同樣會進行警告。

此外，基于鏡像運行的容器業務，也會進行逆向，檢測容器所依賴的鏡像是否正確，鏡像中運行的進程是否與Dockerfile文件中打包的進程名稱相同等。若發現有任何不統一均會會進行告警，報告這個業務存在風險。

云原生是不可變的，不可變的基礎設施包含了底層操作系統與鏡像，因此鏡像也是不可變的。Dockerfile文件是什么樣的，鏡像構建出來一定是對應的。鏡像是什么樣子，運行的容器則一定不會超出這個范圍。

另一個特點功能則是從從代碼倉庫里面直接讀取Yaml編排文件。并對編排文件的權限limit，若發現編排文件中存在廢棄語法、錯誤語法、高危命令等危險參數，都會進行告警。這樣做的目的是要把安全、運維與研發聯動起來。云原生安全一定是運維人員、開發人員和安全人員聯動才能處理，并不是安全部門一個部門的問題。

目前市面上有很多開源的鏡像的組件的掃描，鏡界容器安全防護平臺開源版本與商業版本最大的一個區別是自定義規則和漏洞庫。開源的漏洞庫是基于開源的CBE漏洞庫去實現的，支持中國的CNNVD漏洞庫。中國的CNNVD需要合作才能獲取，正常的開源廠商是拿不到CNNVD漏洞庫的。這是開源和商業最大的本質的區別。

在商業版本中，漏洞的自定義功能，例如可信鏡像、基礎鏡像識別、主機鏡像掃描等功能，開源產品是不存在的。鏡像倉庫存在安全風險，企業內部建設安全能力時，必須對鏡像倉庫自身的漏洞進行掃描。而整個Harbor的安全漏洞小佑是參與維護的，因此在這方面我們有著一定的優勢。

集群組件同樣存在風險的，為了發現集群組件的自身風險，首先需要做集群自身的組合，并基于漏洞庫和漏洞版本比對。同時，對于API接口漏洞與權限漏洞，它是版本比對不出來的，需要用一些POC檢查的方式將整個集群組件漏洞的風險檢查出來。

對整個集群自身組件的配置進行掃描，可以掃描配置自身權限。最早期的K8S默認是不開啟認證權限，現在則默認https。此外，例如審計日志是否開啟等功能，需要基于集群安全，配置合規檢查基線去進行掃描。

在云原生微服務化的場景下，服務拆分會導致量級指數增長，這時便需要安全軟件對微服務的自動發現，并對服務的類型進行識別，以便使用對應的方式去對服務進行自動的漏洞掃描檢測。這是非常節省人力的一種方式。

容器運行后的容器內安全檢測，可以通過兩種模式進行。一種是機器行為學習，通過把容器內部所有的從鏡像開始學習，把容器的行為固化掉，同時對容器的文件讀寫、進程起停和訪問調用進行學習，抓出運行的全部行為，并記錄到行為模型之中，然后將其總結為容器的行為模型。容器運行的所有的流量，均認為它是正常的流量，所有排出的均認為是異常流量。

但學習需要時間，若學習過程中出遭遇攻擊或執行命令，則結果會出現偏差。對此，可以內置了攻擊模型的策略，當發現有行為命中了內置安全策略時，則直接就排除。這樣便能結合機器行為學習防御0 day漏洞，同時防范學習過程中出現攻擊行為這種情況。加之機器行為學習的黑名單內置策略組合，便能夠實現完美的機器運行時安全檢測的閉環。這是目前容器安全運行時的最佳實踐。

在云原生領域中，云原生的微隔離必須要實現以下功能：首先是訪問關系的可視化。由于云原生隔離天生滿足零信任的風險。K8S沒有IP概念，都是基于Label。而Label是研發人員、業務人員所打的標簽，基于標簽來動態做微隔離。因此必須要基于學習關系，自動生成容器的策略，并將策略進行預演。

當策略學習完成并確認后后，便會進入預演模式，此時可以設置預演時間。在一定時間內，所有正常流量，并不會被阻斷。當發現有流量被策略影響時，則會進行警告。研發人員或者業務人員會人為判斷，若業務流量安全，則將機器行為學習模型進行編輯，把其排除到模型之外。

一定時間后，若沒有發現任何其他流量，則學習完的策略完全不會影響正常的流量模式，并且可以防御所有的流量攻擊，這時點擊策略執行，便可在不影響生產業務的情況下，將自動學習到的策略應用到生產環境之中。

最后比較關鍵的一點，在云原生領域中，云原生安全自身軟件的平臺須要符合三層架構：第一層是管理層，管理平臺必須與任務中心解耦，這樣所有的集群才可以匯聚。

當鏡像倉庫的數據量過大時，則可以直接將掃描集成到倉庫鏡像之中，掃描的同時直接讀存儲路徑，而不是靠網絡帶寬去拉鏡像。這樣能夠極大減少了網絡占用和磁盤IO的占用，直接進行讀取。這是目前容器安全的最優的架構設計。

云原生安全最佳實踐

云原生環境下DevSecOps設計主要分為三個部分。第一部分是構建環節。這里小佑科技提供了一個黃金鏡像倉庫，其中是加固過的所有的技術鏡像。研發人員可以直接基于黃金鏡像倉庫去拉取來構建業務鏡像。

小佑與CNNVD有官方合作，其漏洞庫更新后會直接進行同步。小佑也會根據每天的漏洞更新來實時的維護自身的黃金鏡像倉庫。另外，小佑擁有自己的掃描器并有專業的安全研究人員會對最新的漏洞和0 day漏洞進行研究。

推薦企業拆分兩個鏡像倉庫，將生產鏡像倉庫在集群中設置信任判斷。這樣可以有效防止黑客進入集群，并直接拉一個自己的業務容器下來。用一個K8S接口去拉所有黑客自己的鏡像，能夠直接就進行所有的滲透。這種情況下是可以完全避免的。

鏡像的掃描階段是做掃描配置、做業務研發的應用層的掃描配置，如果發現漏洞，則阻止同步。在生產環境中，可以設置一個信任判斷，將所有條件集成到信任判斷之中，例如是否使用了企業自己的環境鏡像倉庫，都可以在平臺上隨意配置。

集群自身的組件與微服務的漏洞的風險評估，也可以使用平臺上的一些功能實現。以鏡像漏洞掃描和分析為例，可以將鏡像分成拆出來，這樣就可以識別出來每一個鏡像依賴于誰做的。技術影響成分、軟件成分分析、源代碼掃描和開發安全掃描、應用漏洞掃描等。

當容器安全平臺檢測到攻擊事件后，會從事前、事中、事后做整體的安全防范。事前對整個集群進行評估、加固，加固完成后將所有的行為學習啟動。進行到事中環節，進行威脅檢查和0 day防御，所有的告警都會實時告警。

當發現攻擊，首先阻止鏡像運行，在研發階段可以阻止鏡像上傳，在倉庫階段可以阻止鏡像下載，在生產環境可以阻止鏡像運行。在容器運行起來后的鏡像，可以自動或者手動執行隔離策略。并設置規則進行自動的處理與手動處理。

對于云原生的網絡安全規劃，由于不同集群間的網絡域是不同的，每個集群之間的物理網絡默認情況下，K8S網絡插件就是overlay的網絡插件，因此網絡域天然會基于集群與集群之劃分網絡安全域。

云原生的微隔離必須支持IP的阻斷，既要兼容零信任的和Label的阻斷方式，又要支持IP的配置，這就是云原生的安全平臺的規劃方式。同時，也需要利用好傳統的安全防火墻，不只要上專用的云原生安全防火墻，還要去結合傳統防火墻進行安全防護。

0day攻擊預防，可以基于五個維度進行建模：

• 通過對容器內行為進行學習，建立安全模型
• 當檢測到模型外的進程、文件訪問、異常網絡連接和系統調用時，通過關聯分析產品風險事件列表
• 人響應處理，及時阻斷異常行為或糾正錯誤
• 在測試環境中生成模型，直接應用于生產環境，無需重新學習
• 零漏洞，支持0 day風險

進程的啟動和停止，在一定的學習周期內，進程所讀寫的文件，都需要進行學習。例如在學習周期后，突然對這樣數據庫嘗試著暴力破解，在短時間內有大量的網絡錯誤、驗證錯誤的攻擊行為，則直接認為不符合學習規范。包括系統調用與配置。

前四個維度，都是學習已經運行的容器行為，最后則是學習未運行之前的行為，并預判運行前的狀態。這是學習的五個維度。并且學習是歷史容器和所有前面容器都會去記錄的，用以0 day攻擊的預防。

?

嘉賓介紹

白黎明，原聯眾游戲云原生平臺負責人，7 年DevSecOps研究建設經驗現為小佑科技技術合伙人。國內第一款云原生安全產品核心設計者，公安部《等級保護 2.0》、信通院《云原生架構安全白皮書》主要起草人。