容器，是未來IT創(chuàng)新和數(shù)字化轉(zhuǎn)型第一驅(qū)動力，這幾年已經(jīng)成為開發(fā)人員最愛。容器構(gòu)造之精密，絲毫不亞于建筑大師蜜蜂所造蜂房。正如達爾文贊嘆蜜蜂的巢房是自然界最令人驚訝的神奇建筑，蜂房是自然界最經(jīng)濟有效的建筑。在這里，青藤推出“蜂巢之聲”欄目，和大家講講堪比大自然鬼斧神工般的容器，其安全該怎么做?

雖然現(xiàn)在容器的使用率還不是特別高，但是許多組織機構(gòu)也正在加速采用容器，容器化是未來發(fā)展的所趨。根據(jù)Gartner預測，到2023年將有超過70%組織會在生產(chǎn)環(huán)境中運行超過3個容器應用程序。如下圖所示，越來越多組織將采用容器化部署應用，對超過一半的應用程序進行容器化處理的組織百分比從23%增至29%，增長率為22%。同時，將少于10%的應用程序打包的組織的數(shù)量從32%下降到21%。

容器化部署應用程序占比

但是，開發(fā)人員常常用不安全的方式來部署容器，而安全團隊卻很少或根本沒有機會參與。如何讓容器更加安全使用?

一、安全左移和自動化是容器安全前提

在當今快節(jié)奏的容器DevOps中，部署容器時，安全人員必須注意容器共享OS內(nèi)核帶來潛在風險、鏡像漏洞、錯誤配置、容器間網(wǎng)絡流量問題。不管是防火墻還是入侵防御系統(tǒng)，并不適用于容器環(huán)境。

此外，隨著現(xiàn)代環(huán)境越來越多地由軟件控制，并實現(xiàn)了自動化，停止作業(yè)進行安全評估已不再可行。標準的做法是盡可能地將安全融入生產(chǎn)，并且通過微服務進行快速迭代。

安全左移

現(xiàn)在容器鏡像是由開發(fā)人員構(gòu)建的，因此，開發(fā)人員承擔了許多其他職責。開發(fā)人員對以前由其他團隊處理的活動所具有的控制權(quán)越來越多，包括一部分測試和運營。

無論是在測試環(huán)境中還是在生產(chǎn)環(huán)境中，由開發(fā)人員構(gòu)建的容器鏡像的運行方式都是相同的。因此，容器鏡像必須是獨立的而且適配各類環(huán)境，只需配置好與容器相關的安全和加固策略，適當調(diào)整可與生產(chǎn)資源連接的基本操作系統(tǒng)即可。

因此，容器安全必須左移，從代碼編寫和編譯時就要確保容器安全。如果在生產(chǎn)過程中解決安全問題必然會產(chǎn)生大量浪費，因為修復發(fā)現(xiàn)的問題就要終止創(chuàng)新管道，并將容器返回到開發(fā)階段。

自動化

容器是DevOps實踐最佳承載方式之一，微服務事實上成為新應用程序體系結(jié)構(gòu)。借助容器化微服務，不同的開發(fā)團隊通過為每個微服務建立并行開發(fā)管道，可將創(chuàng)新速度提高十倍以上。

當這些微服務投入生產(chǎn)時，編排軟件可以對其進行部署和管理。編排軟件是基于策略來運行的，從而讓容器部署實現(xiàn)遠超人工可以實現(xiàn)的效果。這就有效地讓人員從容器化生產(chǎn)環(huán)境運營中抽出身來，讓他們能夠進行策略制定和監(jiān)控異常。這就意味著支持自動化、API和策略運行，從而讓容器具有自行評估和采取措施的能力。

二、全生命周期方案

構(gòu)建階段

（1）安全鏡像掃描

通常，容器鏡像是從根鏡像的基礎上構(gòu)建出來的，根鏡像提供了操作系統(tǒng)組件和應用程序中間件(例如node.js或Tomcat)。然后，開發(fā)人員通過自己的代碼對根鏡像進行拓展，形成微服務的應用程序結(jié)構(gòu)。一般情況下，無需修改即可直接使用Kafka或Vertica等應用中間件。

但是，如果是從Docker Hub等公共倉庫獲取根鏡像時，開發(fā)人員無法了解那些未經(jīng)測試和未經(jīng)驗證的根鏡像究竟會帶來哪些安全風險。因此，需要通過容器鏡像掃描，檢測是否包含了常用漏洞和風險(CVE)，減少最終容器鏡像的攻擊面。

正確的鏡像掃描應包括以下幾個級別：

·進行鏡像掃描，檢查根鏡像，檢測開源鏡像庫中是否有已知的第三方漏洞。

·對配置和部署腳本進行靜態(tài)掃描，及早發(fā)現(xiàn)錯誤配置問題，并對已部署的鏡像進行動態(tài)基礎架構(gòu)加固掃描。

（2）對受信鏡像進行簽名和注冊

在查看容器鏡像時，確保已對其進行了掃描和測試以確保安全。了解這一點很重要，因為這會影響下一個階段(例如轉(zhuǎn)移到生產(chǎn)環(huán)境中)的其他檢查點。

在成功進行鏡像掃描和創(chuàng)建安全評分后，可以對容器鏡像重新簽名，包括安全評分和測試結(jié)果，標明該容器鏡像已經(jīng)過測試并達到特定的安全狀態(tài)等級。

（3）觀察應用程序行為

當開發(fā)人員通過許多容器化的微服務形成其工作負載和應用程序時，網(wǎng)絡將成為應用程序結(jié)構(gòu)。網(wǎng)絡動態(tài)綁定所有微服務。以前，所有邏輯都是在編譯時綁定的?，F(xiàn)在，微服務是解綁的，并根據(jù)需要在運行時與其他服務形成連接。

當然，判斷正常行為和異常行為并非易事。將一個應用程序分解為可服務多個應用程序的微服務時，威脅建模要困難得多。建議在開發(fā)和集成時觀察微服務架構(gòu)，了解哪些是正常行為，這有助于威脅建模。在生產(chǎn)中，可通過威脅模型檢測異常行為，進行隔離。

分發(fā)

（1）審核已知內(nèi)容

隨著容器鏡像從一個鏡像倉庫遷移到另一個鏡像倉庫(不管是內(nèi)部還是外部運行的)，遇到包含未知漏洞的鏡像風險都會增加。容器安全系統(tǒng)需要在通過容器鏡像倉庫時驗證容器鏡像，一旦發(fā)現(xiàn)不合規(guī)情況，就要攔截和隔離相關鏡像。

每次將容器升級到新狀態(tài)時(例如，從開發(fā)到測試或從測試到生產(chǎn))，都應執(zhí)行額外的強制措施，以確保在上一階段為了方便進行調(diào)試/監(jiān)視/基準測試而添加的任何配置不會隨容器本身而進入下一個階段。

（2）審核風險評分

容器和鏡像層的安全策略非常廣泛，因此，很難設置一個人為管理的統(tǒng)一且易于維護的安全策略。對安全策略進行編碼，對每個檢查點的每個容器鏡像生成一個風險評分，這樣就可以實現(xiàn)容器生命周期的標準化，并對每個重要的檢查點中設置最低安全閾值，如果沒有達到最低水平，將對容器生命周期進行控制。

風險評分還有助于促進Dev、Sec和Ops的協(xié)同合作，因為這個統(tǒng)一的風險評分是對這三方的綜合評分，這有助于促進不同團隊和專業(yè)人士保持統(tǒng)一行為。

部署

（1）自動部署

開發(fā)人員正在以不斷加快的速度創(chuàng)建容器格式的微服務。不僅DevOps管道難以管理，而且在生產(chǎn)環(huán)境中，在調(diào)度和編排方面，人工操作要讓位于機器操作，因為編排和調(diào)度程序可以實現(xiàn)容器化微服務的自動化部署。編排程序可以比人做出更好的布局和擴展決策，因此，可以統(tǒng)一穩(wěn)定地實施安全策略。

為了將管理良好的安全狀態(tài)始終維持在一個可接受的水平上，要將容器安全軟件與部署系統(tǒng)聯(lián)系起來，以便您按統(tǒng)一方式遵守安全策略。

基于基礎架構(gòu)即代碼(IaC)原則，要對所編寫的、支持自動化部署任務的代碼進行掃描和驗證，按照應用程序代碼級別，發(fā)現(xiàn)代碼中存在的漏洞。

（2）安全基礎架構(gòu)

在主機上部署干凈無漏洞的容器仍然會有安全風險，需要實施相關的加固最佳實踐，否則，針對流氓容器的保護就太少了。例如，以CIS基準或公司加固策略為基準，查看與加固最佳實踐存在哪些偏差;向管理員發(fā)出警報，并為容器化的基礎架構(gòu)提供安全評分。

（3）用戶和機器審計

通過完整的審核跟蹤，團隊可以調(diào)查導致安全事件的原因，并據(jù)此采取補救措施并實施新的安全策略。這就需要知道誰做了什么，哪個容器編排程序?qū)⒛膫€鏡像部署到了物理或虛擬主機，或者為什么阻止了容器鏡進行部署或訪問給定資源。

容器安全系統(tǒng)需要與人為操作系統(tǒng)和機器操作系統(tǒng)連接起來，對容器基礎設施上發(fā)生的所有事件創(chuàng)建準確的審計跟蹤，并記錄其自身的行動和活動。

運行

(1)秘鑰管理

在很多系統(tǒng)中，密碼和安全令牌之類的秘鑰是安全系統(tǒng)的一個重要組成部分。在主機上部署容器鏡像或訪問基于網(wǎng)絡的資源時需要這些秘鑰。若將秘鑰存儲在容器或環(huán)境變量中，所有有權(quán)訪問該容器的人都會可以看到。

容器系統(tǒng)要求在進行操作(例如容器部署)時使用秘鑰。因此，容器安全系統(tǒng)通常需要訪問秘鑰系統(tǒng)，在容器命令中注入正確的秘鑰進行部署和運行。因此，容器的秘鑰管理需要采用專門解決方案。例如，與HashiCorp的Vault之類的秘鑰系統(tǒng)集成后，僅特定用戶和容器可以訪問特定秘鑰。

(2)與主機隔離

在主機上運行的容器可能會訪問主機資源，例如計算資源、存儲資源和網(wǎng)絡資源。此外，由于容器通常包含微服務，因此從本質(zhì)上講，容器應僅限于一些特定任務，并且每個容器通常負責的任務只有一個。

一旦流氓容器獲得對主機資源(尤其是網(wǎng)絡)的訪問權(quán)限，就可以從網(wǎng)絡上獲取更多資源，進一步滲透到其他主機和系統(tǒng)。應該限制正在運行的容器的訪問權(quán)限，并且這些容器只能使用已批準的特定主機資源，從而限制其對主機和網(wǎng)絡的影響。

(3)容器網(wǎng)絡安全

一臺主機上有多個容器，每個容器都與同一主機或基于網(wǎng)絡的服務上的相鄰容器進行交互，僅依靠網(wǎng)絡安全措施是不夠的，因為主機內(nèi)部發(fā)生的一切對于這些解決方案都是不可見的。

容器安全解決方案需要更靠近主機上發(fā)生事件的地方。比如，通過容器化的agent，它會監(jiān)控所有主機網(wǎng)絡活動，主機上運行的容器的流入和流出，并觀察容器是如何與不同主機的另一個網(wǎng)絡進行交互的。了解了網(wǎng)絡交互情況之后，可以通過網(wǎng)絡流量加固活動來阻止任何異?；顒?。

應根據(jù)在構(gòu)建階段進行的威脅建模，預先規(guī)劃適當?shù)木W(wǎng)絡分段，并對其進行實施和驗證，確保失陷容器盡可能少地影響其他網(wǎng)段，而不會對整個網(wǎng)絡造成重大影響系統(tǒng)。

(4)應用程序配置文件加固

應用程序架構(gòu)是由眾多微服務構(gòu)建而成，每個微服務都具有一個或多個實例，可以實現(xiàn)彈性擴展。應用程序架構(gòu)中的容器在不斷發(fā)生變化，主要由編排產(chǎn)品來實現(xiàn)的。

因此，想要維持正確的應用程序拓撲和觀察異常行為也愈發(fā)困難。例如，異常行為可能是由軟件缺陷帶到了生產(chǎn)環(huán)境中造成的，也可能是通過第三方開放源代碼庫滲透的惡意代碼引起的。

建議，在開發(fā)階段捕獲正常的應用程序拓撲和行為，然后將其用于與生產(chǎn)環(huán)境的實際行為進行對比，從而發(fā)現(xiàn)異常情況。另外，可以先讓應用程序運行一段時間，確定在生產(chǎn)環(huán)境中的預期應用程序，然后再捕獲哪些屬于正常網(wǎng)絡行為，并將其另存為正常應用程序行為配置文件。

三、寫在最后

從簡單的應用容器化，到云原生應用的開發(fā)，容器技術(shù)成為了其最基礎也是最核心的支 撐技術(shù)。新技術(shù)帶來便捷與利益的同時，其安全性也需要引起足夠的重視。近年來，由于容器以及容器應用環(huán)境引發(fā)的安全風險與安全事件不斷的被曝出，容器網(wǎng)絡、容器鏡像、暴露的 API、容器的隔離等問題成為了容器使用時需要著重考慮的問題。

目前，市場上涌現(xiàn)了一批容器安全產(chǎn)品安全廠商，如Twistlock、Aqua等等，國內(nèi)自研容器安全產(chǎn)品的則有青藤云安全?；谇嗵貯gent的主機防護能力，監(jiān)控宿主機上容器相關的文件、進程、系統(tǒng)調(diào)用等等信息，增加其Agent中對于容器的清點、監(jiān)控、防護能力，以實現(xiàn)一個Agent，實現(xiàn)宿主機安全、容器安全兩種防護的效果。

（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。 ）