本文根據7月19日DockOne社羣分享內容整理而成，分享嘉賓蔣運龍，有容雲高級諮詢顧問，一個IT的老兵，十年來混跡於存儲、三網融合、多屏互動、智能穿戴、第三方支付、Docker等行業；經歷過測試、運維、實施各崗位全方位的摧殘，依然活躍在技術的風頭浪尖上。
大家好，我是老蔣，今天和大家聊聊Docker的安全合規建設。
安全，這裏我們指的是信息安全，包括數據安全和網絡安全, 主要是數據在處理、傳輸、存儲等過程中的安全，它包括了信息本身的安全和防護安全。
在安全方面，各行各業甚至國家、國際機構都有很嚴格的標準：1. 歸功於消費領域企業的不懈廣告下， 大家應該都聽過ISO9000（質量管理體系）SO14000（環境管理體系），在安全方面，國際標準化組織也有信息安全標準ISO27000，其中ISO 27001在其中具有核心作用，該標準發佈於2005年，目前最新版爲ISO27001:2013DIS版。
2. 國家在這方面也有信息安全等級保護要求，簡稱等保；它有五個等級，在很多行業等保有硬性要求，如互聯網金融行業至少要符合第四級的等保要求。（見圖1）
3. 各個行業對安全也有專門的標準，如在支付行業，有內卡的非金融機構支付業務設施技術認證JR/T1022-2014，JR/T0213-2014和外卡的數據安全標準PCI_DSS v3.1
說了這麼多，需要重點指出的是，各種標準的發佈和修訂基本上只考慮了虛擬化環境的技術標準。說到虛擬機，我在接觸的很多正在使用或者正準備使用Docker的人總喜歡把容器和虛擬機比較，或者把容器就當中虛擬機在用，嘿！ 說的就是你，還在用Docker Commit 替代Dockerfile！ 還在用SSH連接容器！ 我個人更喜歡把容器比喻成一種沙箱（Sandbox）：每個應用程序都有自己的存儲空間；應用程序不能翻過自己的圍牆去訪問別的存儲空間的內容；應用程序請求的數據都要通過權限檢測，假如不符合條件的話，不會被放行。是不是似曾相識？其實我們的ISO應用就是這種方式執行的。 迴歸正題，事實上，目前行業標準當中所包含的各種準則針對虛擬化技術進行了調整，對於任何想要保護數據的企業來說都可以起到很大幫助作用。使用針對特定行業的標準進行合規審查，可以在很大程度上保證信息處於最佳安全實踐的保障之下。安全的信息環境對於企業、客戶和員工來說都是至關重要的。
Docker技術目前還沒有對應的認證條款，由於比較新，在數據隔離方面是否能夠達到要求還具有不確定性，Docker 的安全性也還不夠強健，只要具備Docker權限的用戶都可以對Docker容器進行所有的操作。這無疑將增加審覈範圍及邊界的不確定性。 另外，Docker在當前階段還在快速推出更新版本，也存在不兼容的情況，等待未來版本和安全性問題解決之後或許會有文件來指導合規過程。目前我不推薦大家直接用於認證環境。 幸運的是， 關於Docker這種虛擬化技術背景的產品，標準要求本身是沒有變化的，可以按虛擬技術進行評估。我們可以在業務相關的環境當中將Docker作爲虛擬化技術的使用準則之一。比如，在PCI DSS第2.2.1章節當中指出一個虛擬系統組件或者設備只能實現一項主要功能，這正是容器的特點之一。 對於非認證的生產及非生產環境，我這裏有一些Docker使用上的經驗和心得和大家分享一下：
內核安全
所有進程運行在同一個內核中，即使有多個容器，所有的系統調用其實都是通過主機的內核處理，因此該內核中存在的任何安全漏洞都有可能造成巨大影響。如果某套容器系統導致內核崩潰，那麼這反過來又會造成整臺主機上的全部容器毀於一旦。
在虛擬機當中，情況則要好得多：傳統的虛擬機同樣地很多操作都需要通過內核處理，但這只是虛擬機的內核，並非宿主主機內核。因此萬一出現問題時，最多隻影響到虛擬系統本身。當然你可以說先攻破Hypervisor,再攻破SELinux，然後攻破宿主主機內核就可以控制宿主機上的所有虛擬機，先不說虛擬機發展這麼多年存在的漏洞還有多少，光虛擬機內核→Hypervisor→SELinux→宿主主機內核這幾層的隔離的安全性和容器就不是一個數量級上的。所以建議大家密切關注內核的安全。在內核安全的合規建設上，虛擬機和容器的要求是一致的，大家完全可以遵從當前的行業標準。拒絕服務***
所有容器都共享同樣的內核資源。如果某套容器能夠以獨佔方式訪問某些資源，那麼與其處於同一臺主機上的其它容器則很可能因資源匱乏而無法正常運轉。這正是拒絕服務***(簡稱DoS)的產生原理，即合法用戶無法對部分或者全部系統進行訪問。在這方面大家亦可參考虛擬機時代的經驗，預估應用的資源消耗上限，設計更多的Cgroups，用於控制那些打開過多文件或者過多子進程等資源的進程，對容器資源進行限制，如CPU使用率，內存上限等，雖然容器的隔離性沒虛擬機那麼徹底，但至少能保證業務的連續性。鏡像安全
還有一部分來自於鏡像本身的安全。由於Docker Hub 上的鏡像成千上萬，甚至國內各種PaaS雲服務公司提供的鏡像倉庫，如果***者誘導用戶下載由其精心設計的鏡像，那麼運行的主機與數據都將處於威脅之下。建議大家使用可靠來源甚至是官方的鏡像，並檢查是否存在篡改。同樣的，大家還需要確保自己運行的鏡像爲最新版本，且其中不包含任何存在已知安全漏洞的軟件版本。用戶權限
如果大家在容器內擁有root權限，那麼在主機上亦將具備root身份。在系統中非root用戶只要加入Docker用戶組，就無需使用sudo的情況下運行Docker命令。同樣，添加了--privileged參數運行的容器也將獲得主機的完全控制權。這種情況，首先，建議大家儘量不要使用--privileged參數，若實在有業務需求，可以將所有需要--privileged參數的容器嚴格控制在一臺或某幾臺主機以隔離其他容器。其次，建議大家配合sudo來增加用戶的審計和日誌功能，在/ect/sudoers中添加以下內容： user ALL=(ALL) /usr/bin/docker ，這樣user使用Docker命令的時候需要密碼驗證，並會在系統中記錄所有的操作日誌用於審計。文件完整性
有些Linux系統的內核文件系統必須要mount到容器環境裏，否則容器裏的進程就會罷工。這給惡意進程非常大的便利，但是大部分運行在容器裏的App其實並不需要向文件系統寫入數據。基於這種情況，建議在mount時使用只讀模式，如 –v /etc/localtime:/etc/localtime:ro 總之通過適配、加固的Docker容器方案，在安全性上完全可以達到商用標準。就是可能對實施人員的技術要求和門檻較高。
今天的分享就暫時到這裏，謝謝大家的傾聽，也歡迎大家多多交流，謝謝！