【51CTO.com快譯】從技術(shù)上講，相比過去那些重量級的虛擬機(jī)，Docker為軟件開發(fā)人員提供了可擴(kuò)展的數(shù)據(jù)包和發(fā)布代碼的容器，為應(yīng)用程序的靈活性和可移植性需求提供了一種可持續(xù)的業(yè)務(wù)模型。而作為一種基于云的存儲庫，最終用戶既能夠在Docker Hub中發(fā)布各種Docker鏡像，又可以將它們拉出來，用于各種云原生基礎(chǔ)架構(gòu)的部署。由于Docker鏡像不但輕巧、可移植，而且能夠在系統(tǒng)之間輕松地被移動，因此任何人都可以創(chuàng)建一組標(biāo)準(zhǔn)化的Docker容器鏡像，將其存儲在存儲庫中，以便通過Docker Hub在整個組織中共享它們。

Docker鏡像的威脅

不過，用戶不能盲目地并從Docker Hub中直接提取鏡像。僅在2018年，Docker Hub上就被發(fā)現(xiàn)了17種惡意Docker鏡像(請參見--https://threatpost.com/malicious-docker-containers-earn-crypto-miners-90000/132816/)，攻擊者已從中牟利90,000美元。由于Docker Hub中帳戶和項目是相互聯(lián)系的，一旦安全漏洞被發(fā)現(xiàn)，準(zhǔn)確地找到那些可能受到嚴(yán)重影響的資產(chǎn)，會是一項艱巨的任務(wù)。同時，這也會減慢從開發(fā)到運營、再到部署的整個過程。因此，DevOps團(tuán)隊不得不花費大量的時間，通過跟蹤鏡像的自動構(gòu)建與存儲，既檢查相關(guān)帳戶和項目中的可疑活動，又需要重設(shè)已感染帳戶的密碼，刪除并替換已受攻擊的鏡像。

Docker許可證的風(fēng)險

Docker鏡像往往是由那些具有不同許可證條款和合規(guī)性義務(wù)的軟件，以及操作系統(tǒng)包所組成。為了在企業(yè)中管控容器使用的風(fēng)險，我們需要了解所有這些依賴關(guān)系，以便根據(jù)公司的安全準(zhǔn)則、以及開源策略進(jìn)行合規(guī)性評估。

在實際操作中，我們可以借用自動化工具來識別鏡像，獲悉操作系統(tǒng)的所有軟件包、已捆綁的應(yīng)用、以及從屬庫，進(jìn)而匯總各個層面上的許可證，以便識別出不合規(guī)的軟件包，最終降低企業(yè)在法律和業(yè)務(wù)上的風(fēng)險。例如，由JFrog提供的Xray是一種常見的安全掃描解決方案。它可以通過深入到Docker鏡像中，來識別許可證的合規(guī)性，并在安全研究人員發(fā)現(xiàn)了新的安全漏洞時，及時對其進(jìn)行標(biāo)記。

緩解風(fēng)險

基于安全方面的考慮，Docker Hub在提供服務(wù)的同時，采取了如下兩個方面的限制：

• 鏡像保留限制

那些使用免費賬號(這在開源項目和自動化構(gòu)建中十分常見)在DockerHub上存儲的鏡像，會受到六個月的鏡像保留政策限制。也就是說：如果這些鏡像在六個月后處于非活動狀態(tài)，那么就會被直接刪除掉。

• 下載節(jié)流

Docker對匿名用戶引入了“每六小時只允許100次請求”的下載速率限制;而對于免費帳戶，則采取了“每六小時只允許200次請求”的下載速率限制。

由此，會有兩組人員可能會受到此類限制策略的影響：創(chuàng)建Docker鏡像的開源貢獻(xiàn)者和使用鏡像的DevOps愛好者。具體說來，開源貢獻(xiàn)者會碰到丟失那些少用但重要的鏡像等問題。而由于DevOps愛好者會將Docker Hub用作存儲系統(tǒng)，因此碰到在沒有任何警告的情況下，丟失鏡像或破壞構(gòu)建等問題。并且由于請求次數(shù)的限制，他們的匿名或免費構(gòu)建也可能出現(xiàn)失敗。

面對此類狀況，我們可以選用一種更為高效的替代品--Artifactory。

如上圖所示，Artifactory的應(yīng)對措施包括：

• 由于Artifactory能夠緩存鏡像，因此用戶不會受到上游鏡像被移除的影響。
• 由于Artifactory能夠提供緩存服務(wù)，因此每個鏡像只需被拉取一次，有效地實現(xiàn)了節(jié)流。
• 整個組織內(nèi)的所有開發(fā)人員和構(gòu)建主機(jī)都只需要一個Docker Hub許可證。
• Artifactory允許用戶為每個實例創(chuàng)建多個Docker注冊表。您可以將本地存儲庫用作私有的Docker注冊表，以細(xì)粒度的訪問控制方式，在整個組織中共享Docker鏡像。
• 您可以存儲和檢索任何類型的工件(artifact)，甚至是由開發(fā)團(tuán)隊生成的安全Docker鏡像。由于這些工件存儲在中央托管位置，因此Artifactory成為了任何軟件交付生命周期的重要組成部分。

JFrog Artifactory的基本特征：

• 提供2 GB的存儲空間和10 GB傳輸?shù)拿赓M套餐
• 處于大型組織的商業(yè)層

作為一種無縫托管和分發(fā)容器鏡像的服務(wù)，Artifactory能夠?qū)⑺卸M(jìn)制文件存儲到單個位置(如：Docker注冊表，https://jfrog.com/integration/docker-registry/)，以實現(xiàn)對進(jìn)入某個Docker鏡像的內(nèi)容和信息進(jìn)行管控。同時，Artifactory也提供了廣泛的集成、高可用性、高安全性、大規(guī)模的可擴(kuò)展存儲，以及能夠通過持續(xù)更新，來支持最新的Docker客戶端版本和API。

JFrog容器注冊表(JFrog Container Registry，JCR)的基本特征：

• 自托管：提供免費且無限制的容器注冊表
• Cloud SaaS：2 GB的存儲空間和10 GB傳輸?shù)拿赓M套餐
• 云端BYOL(Bring Your Own License，自帶許可)：在用戶自己的基礎(chǔ)架構(gòu)上是免費的

JFrog容器注冊表能夠與Docker完全兼容，用戶可以使用各種工具按需進(jìn)行“原生”操作，從而實現(xiàn)對Docker鏡像的管理(請參見--https://www.jfrog.com/confluence/display/JCR/Docker+Registry)。

JCR可以被作為我們管理所有Docker鏡像的單一節(jié)點。通過集成到已構(gòu)建的生態(tài)系統(tǒng)中，用戶可以安全、可靠、一致、高效的方式，訪問到遠(yuǎn)程的Docker容器注冊表。

服務(wù)管理員可以按需使用細(xì)粒度的權(quán)限控制，來維護(hù)任意數(shù)量的公共和私有Docker注冊表。同時，它還為用戶的容器存儲了豐富的元數(shù)據(jù)，以提供容器內(nèi)各個層面上的唯一且全面的視圖。用戶可以據(jù)此了解其中的具體內(nèi)容。

建立可持續(xù)的容器生態(tài)系統(tǒng)

擁有蓬勃發(fā)展的容器生態(tài)系統(tǒng)，對于那些正在使用Docker和Kubernetes等云原生技術(shù)來實現(xiàn)成功部署的公司來說，是至關(guān)重要的。通過在企業(yè)內(nèi)部部署JFrog Artifactory和JFrog Container Registry之類的本地存儲技術(shù)，我們不但可以靈活地支持構(gòu)建、測試和部署等各種實用場景，還能夠減少各種共享式社區(qū)基礎(chǔ)架構(gòu)的負(fù)載，其中包括：Docker Hub、Maven、NPM、Go、Conan、以及其他由社區(qū)運營的中央存儲庫。

雖然我們在使用Docker Hub時可能會遇到上游容器鏡像被刪除，以及服務(wù)受限或中斷等風(fēng)險，但是通過部署工件管理系統(tǒng)，用戶能夠在實現(xiàn)流暢地端到端軟件交付的同時，更加專注于軟件包的質(zhì)量和安全性，而不僅僅著眼于擴(kuò)展基礎(chǔ)架構(gòu)。

原標(biāo)題：Mitigating DevOps Repository Risks ，作者: Pavan Belagatti and Stephen Chin

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】