云原生發(fā)展趨勢

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

• 符合云原生應用12因素

• 面向微服務架構

• 自服務敏捷架構

• 基于API的協(xié)作

• 具有抗脆弱性

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

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

• 應用容器化

• 面向微服務架構

• 應用支持容器的編排調度

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

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

• 容器化

• 服務網格

• 微服務

• 不可變的基礎設施

• 聲明式的API

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

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

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

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

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

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

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

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

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

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

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

云原生安全風險

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

• 鏡像安全

• 鏡像倉庫安全

• 集群組件安全

• 容器網絡風險

• 微服務風險

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

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

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

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

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

云原生安全架構設計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

云原生安全最佳實踐

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

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

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

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

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

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

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

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

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

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

• 通過對容器內行為進行學習，建立安全模型

• 當檢測到模型外的進程、文件訪問、異常網絡連接和系統(tǒng)調用時，通過關聯(lián)分析產品風險事件列表

• 人響應處理，及時阻斷異常行為或糾正錯誤

• 在測試環(huán)境中生成模型，直接應用于生產環(huán)境，無需重新學習

• 零漏洞，支持0 day風險

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

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