有人說Docker Hub上三成的鏡像包含漏洞？是嗎？
到底Docker Hub上是否三成的鏡像存在漏洞?通過漏洞計算發現確實有高比例漏洞，對于官方鏡像遵循Docker的安全指南，如若是自創建鏡像，可找源倉庫或自行處理。但我們發現，這些漏洞中大部分是老鏡像。面對漏洞鏡像，我們可以采取本地措施，還可用Web安全審查進行檢查，如果想讓Docker更加安全，建議用dockerbench來評估。文中額外闡述了容器究竟有什么用。
這個數字太神奇了!并不是因為這個比例過高或者過低，而是因為居然存在這個比例。既然存在(相對容易地)計算出這個比例的可能性，也就意味著存在(相對容易地)改善這個比例的可能性。
聲明：我是Docker官方人員，然而我寫這篇文章并未受到公司批準，所以***帶著批判的思維來讀本文。
這個數字來源于BanyanOps的博客。
漏洞的計算
首先，來看看怎么才能計算出原文中的數據。這過程比較簡單：
- 獲取Docker注冊表的一個列表
- 下載列表中的鏡像
- 檢查鏡像中的漏洞
這步驟看起來似乎太簡單，我們稍微深入下細節。
列舉鏡像
列舉官方的鏡像是容易的。這些鏡像是基于一個叫bashbrew的自動化系統構建而來的，使用的都是公布于眾的方法。順便一提，這意味著如果你想重建官方的鏡像，做起來也會很容易。(記住那些方法中涉及一些blobs或者tar包，是在啟動的時候用到的;因而有時你要多費一點力，重建這些blobs或者tarbal)。
構建官方鏡像的方法在Github上的docker-library倉庫可以找到。
要列出其他的鏡像(即屬非官方的用戶和機構所有的鏡像)要困難點。Docker Hub目前沒有提供什么方法來列舉他們，所以一個暫時可行的方法是搜索一個十分寬泛的關鍵字，然后對其結果進行提取。當然，這需要一些抓取的工作;抓取到的結果可能會漏掉一些用戶的數據，但是你拿到的結果已經會十分接近了。(雖然這么做肯定可行， 我也聽說新的注冊表接口有一些十分好的特性，可以讓這一步完成起來容易點)。
下載鏡像
下載鏡像是一個繁瑣的任務。如果你想安安靜靜的做這件事情，運行一個docker的守護者進程，然后執行docker pull username/imagename:tag即可。
如果你想拿到容器的文件系統的一個tar包，也很容易：只需要運行docker export username/imagename:tag就行。(記得把標準輸出重定向到其他地方，否則你的終端會抓狂的)
如果你不十分相信Docker的守護者進程，你可以檢查registry的接口(v1，v2)并且通過接口來下載層，然后把層文件重組成鏡像文件。一些細節我想留給你自己去做，但是層文件只是普通的tar包，你只需要在彼此之上解包(需要保持正確的順序)就可以重組成鏡像文件。沒有什么特別難的步驟;唯一需要留心的地方就是“留白”(whiteout)。“留白”是特殊的標記文件，用來表明“此處曾經有文件存在于此，但目前沒有了”。換句話說，如果一個層包含文件/etc/foo.conf，但是之上的層把其刪除了，上一層就會包含一個/etc/.wh.foo.conf文件，并且foo.conf不會出現在容器里面。這個文件相當于被留白文件加上了蒙板。
我后來發現，了不起的Tianon已經為此寫好了一個腳本，如果感興趣你可以去看看。
#p#
檢查鏡像
在這個階段你有幾件事情需要做。細節繁瑣，本文無法全部敘述;但是在一個全面的安全檢查中，下面這些步驟你可能需要做：
- 運行yum-security或者類似的命令，保證在此刻沒有安全更新;
- 或者更好的做法是：列舉出所有安裝的包及其版本，然后檢查軟件包在該版本是否包含漏洞;
- 計算系統中的每一個文件的hash值，然后去跟已知的有漏洞的文件的hash集合去做比較;
- 執行自動化工具(如chkrootkit)尋找可疑的文件;
- 運行一定數量的專門為某些漏洞而打造的漏洞測試。這些測試的目標是嘗試利用某些漏洞，然后告訴你，“你的系統有漏洞，因為我已經設法利用了這個漏洞”或者“我無法利用這個漏洞，所以你的系統很可能沒有此漏洞”。
事情到了容器的環境中變得很有趣，因為用Docker來自動化這些步驟容易且便捷。例如，你可以將你的漏洞分析工具包放在/tmp/toolkit中，然后對于每一個鏡像$I，執行docker run -v /tmp/toolkit:/toolkit $I /toolkit/runall.sh。
(注意：這里假設你的工具包是靜態鏈接并且/或者是自包含的，如不依賴你容器鏡像中的任何地方，因為這又可能讓你的工具包收到蒙騙。我這里主要想說的是，如果你想用一系列的測試來檢查你的容器鏡像，你可以用容器讓這個步驟變得很簡單，并且整個過程會更加的快速，因為對于每一個測試你不需要單獨做一個檢查的機器的拷貝)
提升指標
那么在我們運行完這些測試，然后發現出奇高比例的鏡像包含有漏洞的包。我們怎么來改善這個指標呢?
對于官方的鏡像，最容易的方法是遵循Docker的安全指南。以后隨著官方鏡像數的增長，Docker也會改善這個機制，達到自動提示官方鏡像的上游安全列表的效果。
對于非官方的鏡像，你可以檢查鏡像中的Author字段：
- $ docker inspect --format '{{.Author}}' bin/ngrep
- Jerome Petazzoni
如果該鏡像是自動構建出來的，你可以找到其來源的倉庫，并且直接聯系他們。
如果你直接受到了漏洞的影響，想事情進展的更加快速，你可以自己重建鏡像，并且/或者研究怎么才能修復這個漏洞，然后提交一個包含相應修復的PR。這里的意圖不是把安全的責任推卸到鏡像的使用者身上，而是讓有意愿和有能力修復這些漏洞的人能對Docker鏡像的安全做貢獻。
在將來，這些步驟會完善，并且流式化。會有自動化的過程構建出來減少需要聯系相關機構的煩瑣，然后盡量降低發布包含漏洞補丁版本的時間。
但是30%還是太高了，對不對?
30%的“有漏洞的鏡像”可能聽起來非常多。我***次聽到也是這么想。但是如果你細看，你會發現其中一大部分的鏡像是老的鏡像，它們是__故意不被更新__的。
什么?__故意不被更新__?
是的，并且對此有一些好的解釋。***個是(其中的一部分)照顧其他的媒介。有的發行版想XYZ想在CD/DVD，網絡安裝，VM鏡像，和容器都保持一致。第二個原因是(這也解釋了***個原因)可重復的構建。
設想你有一個服務器跑著12.04，但是你用一個新的Ubuntu 12.04的版本(更別提14.04)卻重現不出來。在更加深入的研究后發現，這個問題只存在于那些在某特定時間安裝的機器，其版本是12.04.02。如果一個容器鏡像有12.04.02的版本，你可以重現出這個bug;否則，你得從其他地方得到這個特定版本。這就是為什么Docker Hub有很多老的鏡像，它們保持著發行時的狀態 - 同時包含當時發行時的安全問題。盡管這么說，我們已經放置了安全警示說“歷史的鏡像 - 保持遠離”，所以我們比較希望這鏡像在計算出這些安全的指標的時候不應該被包含進去。
讓我們希望下次有人在計算安全指標的時候他們能意識到這一點。
在本地采取措施
我們可能跑著有漏洞的鏡像!求救!怎么辦，怎么辦?
事情沒有其看起來那么糟。當你(或者其他人)做完對于這些鏡像(官方的，公開的，私有的)的審查，結果是一個鏡像的列表(以一個唯一的hash 串)，并且包含“PASS”或者“FAIL”的狀態。(對于“FAIL”的鏡像，你可能想知道一些其為何不通過的細節，如：“好像有 ShellShock/CVE-2014-7187和其他漏洞”或者“包含軟件包OpenSSL 1.0.1c / CVE-2014-0160”。)
Web規模的安全審查
你可以拿著這個列表，然后與你本地的鏡像做比較。這里就是事情變得有趣的地方。根據本地鏡像和這個列表做一個簡單而廉價的匹配結果，你就馬上能知道你是否運行著有漏洞的鏡像。這可以很容易的擴展到成千上百萬的主機。
這也意味著事情可以很好的解耦：你的安全審查員不需要訪問你的生產環境(甚至不需要訪問你的開發環境中的系統)。他們甚至不需要要知道你運行著什么鏡像：他們只需大面積的對鏡像做分析，然后得出結果給你。你甚至可以從幾個安全公司那里拿到結果然后比較他們的結果。
#p#
我的鏡像在創建后修改過怎么辦?
對于新手，你不應該這么做。如果你像更新容器中的某些東西，你應該創建一個新的鏡像然后運行該新的鏡像。好吧，但是我已經這么做了該怎么辦?
那真是什么都說不準，但是至少我們能知道你這么做了。安全審查的一部分，你可以在運行的容器上運行docker diff來知道是否他們被修改了。(通常docker diff是沒有結果的。注意你已經用shell啟動了一個容器，或者在容器內執行過docker exec，你可能會看到少許的更改。但是生產環境的容器不應該出現任何的更改結果。)
專業的Tip：你甚至可以防止更改，通過在容器中使用--read-only的標記來達到這一點。這會讓容器的文件系統只讀，保證docker diff的結果為空。
如果你想用一條命令來檢查所有的容器，可以執行：
- docker ps -q | xargs -I {} dockr diff {}
(感謝@diogomonica提供命令!)
我已經構建了自定義的容器怎么辦
如果你構建了自己的容器，我建議你把他們上傳到一個倉庫里面。如果這是一個公共的，我們就會到最初討論的情形。如果這是一個私有的，讓我們看下一個部分!
私有的鏡像和注冊表該怎么辦?
如果你上傳的是私有的鏡像怎么辦?如果你上傳的地方是一個本地的注冊表，或者Docker Hub的企業版怎么辦?
事情顯然變得更加復雜了。你可能會看見有人告訴你“設想ABC有CVE-XYZ的漏洞”如果他們從來沒有看到過鏡像ABC。
這里是一些可能會發生的事情：
安全提供商可以提供鏡像的掃描器，你可以用在自己的鏡像上;
安全提供商可以更進一步，將其集成到Docker的注冊表中。這可以通過分配讀權限(訪問Docker Hub上的私有鏡像)或者部署前置(on-prem)的安全掃描器(對于Docker Hub企業版的情形)來實現。在兩個情形中，都能達到一旦鏡像上傳就會被自動掃描的效果，并且立即報告任何可能包含的漏洞。
結論
有兩點我想強調，因為我相信這能在安全領域產生好的結果。
得出數字是好的。一旦我們得到了量化的數據，我們可以提升他們。Docker對于安全問題十分延嚴肅，你可以很肯定我們會和社區及鏡像的維護者一期來改善這些量化數據。
有類似這樣的圍繞著Docker和Docker Hub的生態環境和社區，讓他們成為一個樹立標準的地方。正如Soloman在一些keynote里面指出的，Docker里面最重要的一點不是技術，而是讓人在某事上達成一致。
后一點意味著Docker現在有足夠的批評群體來校正橫向的工具(包括安全審查)來讓這個生態環境受益。其結果會是更加完善的安全機制，讓每一個人受益。
Docker注重安全
如果有Docker公司不在乎安全的印象，那真相離你就太遠了。正如上面指出的，我們有一個負責的披露安全的政策，并且我們總是很快的解決我們意識到的問題。沒有哪個軟件是沒有bug的。Docker也是由人類編寫出來的，即時他們有些人十分的了優秀，但是還是會犯錯。重要的是我們對待安全報告的嚴肅態度如何，我們解決這些問題的速度如何;我想我們在這些方面都一直做的很好。
如果你想讓你的Docker的環境更加安全，我推薦你看下dockerbench。我參與了其編寫，該軟件包含了一個自動化的評估工具可以用來評估Docker的主機，使用的是CIS Docker 1.6 Benchmark。它會檢查很多事情(如是否SELinux和AppArmor是啟用了的)然后生成一個報告。
這是Docker會推出或者參與的一大批軟件的***批，目的是讓你可以在沒有Docker容器安全方面的Ph.d的證書的情形下，或者在沒有聘請一個Taylor Swift的情形下，安全地運行Docker。
并且，我們鼓勵公開的討論，安全的擔憂也不例外。Docker Library的倉庫里面有一個十分有趣的有關于這個話題的討論。
額外的提示
有人問我闡釋下容器究竟為什么有用，如果我們不反復的檢查我們運行的所有的東西的來源。這里是一些例子：
- 容器讓我們可以在沙箱環境下測試一些危險的操作(如著名的curl ...| sh)，并且可以查看到底能產生結果，這得益與docker diff。
- 容器讓我們可以在沙箱環境下測試一些危險的操作(比如一個商用軟件的install.sh)，并且可以查看到底能產生結果，這得益與docker diff。
- 容器讓我們可以在沙箱環境下測試一些危險的操作(如安裝一個npm，pip，gem等等的包，但是我們不清楚其來源)，并且可以查看到底能產生結果，這得益與docker diff。
- 容器讓我們可以在沙箱環境下測試一些危險的操作(如安裝一個deb，rpm或者其他的發行版的包)，并且可以查看到底能產生結果，這得益與docker diff。
- 容器讓我們可以在沙箱環境下測試一些危險的操作(如安裝一個危險的squid包)，并且可以查看到底能產生結果，這得益與docker diff。
- 我猜想你能看出這個模式。僅僅因為事情以一種熟悉的形式呈現給你并不代表它們是安全的。但是我們可以使用Docker來提升安全性。
