有容雲：上車 | 聽老司機談Docker安全合規建設

編者注： 本文根據7月19日DockOne社群分享內容整理而成，分享嘉賓蔣運龍，有容雲高階諮詢顧問，一個IT的老兵，十年來混跡於儲存、三網融合、多屏互動、智慧穿戴、第三方支付、Docker等行業；經歷過測試、運維、實施各崗位全方位的摧殘，依然活躍在技術的風頭浪尖上。之前分享過《老司機帶路 | 使用Docker實現絲般順滑的持續整合》，線上閱讀可直接點選。

大家好，我是老蔣，今天和大家聊聊Docker的安全合規建設。

安全，這裡我們指的是資訊保安，包括資料安全和網路安全, 主要是資料在處理、傳輸、儲存等過程中的安全，它包括了資訊本身的安全和防護安全。

在安全方面，各行各業甚至國家、國際機構都有很嚴格的標準：

1. 歸功於消費領域企業的不懈廣告下， 大家應該都聽過ISO9000（質量管理體系）SO14000（環境管理體系），在安全方面，國際標準化組織也有資訊保安標準ISO27000，其中ISO 27001在其中具有核心作用，該標準釋出於2005年，目前最新版為ISO27001:2013DIS版。

2. 國家在這方面也有資訊保安等級保護要求，簡稱等保；它有五個等級，在很多行業等保有硬性要求，如網際網路金融行業至少要符合第四級的等保要求。

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容器方案，在安全性上完全可以達到商用標準。就是可能對實施人員的技術要求和門檻較高。

今天的分享就暫時到這裡，謝謝大家的傾聽，也歡迎大家多多交流，謝謝！

Q & A

Q1、容器安全和虛擬機器的安全有什麼異同？ A:容器可以在更細的顆粒度上來保護應用，比如說物理機好比大樓，虛擬機器好比不同的房間，容器就是裡面同房的租戶，大樓及房間保障了外部的安全，如果你不相信同屋的租客，則需要用容器來更強的隔離，這是2個不同角度的問題。

Q2、映象安全，Clair掃描靠譜麼？ A:Clair是CoreOS釋出的一款開源容器漏洞掃描工具。該工具可以交叉檢查Docker映象的作業系統以及上面安裝的任何包是否與任何已知不安全的包版本相匹配。漏洞是從特定作業系統的通用漏洞披露（CVE）資料庫獲取,它偏向於靜態掃描，即映象安全，國際上對容器執行時安全方案涉足較少，國內容器雲對安全更是空白一片。

Q3、Docker有一個user namespace的機制，這種隔離在正式的安全規範裡有相應描述嗎？有沒有嘗試過利用這種機制增加安全性？ A:Docker的安全標準規範基本處於空白階段，大家都在摸索，主要是實踐累計。user namespace可以增強一定的隔離性，但是剛才也提到：用user namespace隔離後，其實太多使用者不會用操作日誌，用於後期追蹤及審計。

Q4、能介紹下沙箱與容器的不同嗎？ A：沙箱和容器只是在工作的方式上比較類似，但是底層的技術實現和程式碼其實是完全不一樣的。

Q5、如何才能有效的檢測出下載的映象是否含有木馬等不安全的資訊呢?掛載到容器中的目錄，如何給只讀許可權，後續資料庫一些資訊想寫入宿主機又如何實現? A：對映象掃描目前世面上還是有一些產品的，比如說剛才某位同學提到的Clair。 掛載到容器的目錄可以通過ro引數設定只讀許可權，但是需要寫入的目錄掛載只設只讀許可權程式是不能執行的，這樣就涉及到宿主機的檔案安全，相信宿主機的安全產品及方案，現在已經很多，就不復述了。

Q6、木馬檢測涉及到特徵程式碼庫，檢測比較難吧？ A：木馬檢測其實都是基於目前的技術， 只是容器的數量可以遠遠大於虛擬機器，這樣對檢測的效能和時效有了更高的要求。

Q7、最近一直被人問到安全性的問題，但是隻從單機角度考慮安全性是否已經無法滿足分散式計算環境，我們是否更應該從分散式計算帶給我們的規模效應和自愈機制來重新審視Docker的安全標準，請問嘉賓是如何看待分散式計算中的整體和部分，以及它們之間的安全關係，謝謝。 A：分散式也是由節點組成的，單機安全是基礎，如果單機安全性都無法滿足，分散式的安全更無從說起。 當然，分散式存在大規模效應，節點更多需要關注的是資料的處理及儲存安全；在滿足了節點安全後，分散式更多的應該是考慮跨節點之間的資料傳輸安全，尤其是跨公網的資料傳輸(VPN 隧道也是屬於跨公網的傳輸一種)。自愈機制其實應該算保障業務連續性的一種方式，當然也可以歸納為安全的一種。

Q8、請問Rancher 除了使用“環境”外，目前能完美實現租戶隔離嗎？ A：可以使用主機標籤+容器策略的方式，將不同使用者用虛擬機器或物理機進行隔離。 就目前Rancher來說，不同環境是比較好的隔離方案。

Q9、不知道嘉賓給的安全建議是否適用於CoreOS這種Docker 化的OS，還是說這類OS 會有更好的合規功能？ A：CoreOS這種系統確實更適合容器，而且承載的功能也更加少，相應的需要合規的點也越少。 但是不排除某些合規要求強制的功能點無法滿足，這需要根據實際情況來判斷。

Q10、有沒有相應的容器安全落地方案，應用需要進行改造嗎？ A：有容雲很快將會出一款AppSafe的產品，不需要對應用進行改造。 當然，發現了問題後可能要從應用入手解決。

Q11、除了映象掃描，還有哪些容器安全需要注意的地方，和哪些成熟方案呢？ A：除了映象掃描，還需要關注容器執行時安全，如網路安全，應用程式漏洞，防止被攻擊，安全策略等； 相信接下來有容雲釋出的AppSafe產品不會讓大家失望。

Q12、虛擬機器的安全方案是否也同樣適用於容器？ A：應該是部分適合，剛才提到容器和虛擬機器關注點是不一樣的。 虛擬機器更多是系統安全+應用安全， 容器的主要關注點還是應用安全，如程式碼漏洞，軟體漏洞等等

Q13、如何評價Docker 1.12中Swarm模式自帶的TLS認證? A：大家都知道前段時間的心血漏洞，大家也知道目前網際網路環境的情況， 其實TLS認證已經是很多環境的必備要求，甚至對TLS的版本號也是嚴格的要求，比如說某些行業必須使用TLS1.2以上的版本才能合規。Swarm模式自帶的TLS認證相信也是基於此類要求。

偷偷告訴大家一個好訊息 有容雲的容器安全產品AppSafe即將上線啦！ 企業級、輕量級、雲規模、分散式 保障容器靜態資源及執行時安全 想了解更多相關訊息？ 趕快報名有容雲的Docker Live時代線下交流活動啊 7月31日我們相約北京 瞭解詳情戳這裡 《Docker Live時代 | 暢聊容器生態之線下系列-北京站》 直接報名請點選 ↓↓↓ http://www.youruncloud.com/videos/offLiveMeetup.html#start 本文來源：http://www.youruncloud.com/blog/87.html

溫馨提示 對Docker容器技術或容器生產實施感興趣的朋友歡迎加群討論。我們彙集了Docker容器技術落地實施團隊精英及業內技術派高人，線上為您分享Docker技術乾貨。我們的宗旨是為了大家擁有更專業的平臺交流Docker實戰技術，我們將定期邀請嘉賓做各類話題分享及回顧，共同實踐研究Docker容器生態圈。 加微信群方法: 1.關注【有容雲】公眾號 2.留言”我要加群” QQ群號:454565480