[[123732]]

在審查Docker的安全時，需要考慮三個主要方面：

• 容器內在的安全性，由內核命名空間和cgroup中實現;
• docker守護程序本身的攻擊面;
• 加固內核安全特性，以及它們如何與容器中互動。

一、內核和制組

內核 命名空間 Kernel Namespace

Docker容器中非常相似LXC容器，并且它們都具有類似的安全功能。當您以“docker run”啟動一個容器，后臺Docker為容器創建一組命名空間和控制組的集合。

命名空間提供隔離的最初也是最簡單的形式：一個容器中運行的進程看不到運行在另一個容器中或者在主機系統中的進程，甚至它們之間更少的影響。

每個容器也都有自己的網絡協議棧，這意味著容器沒有得到特權訪問另一個容器的套接字或接口。當然，如果主機系統是設置因此，容器中可以相互通過各自的網絡接口進行交互 ——就像他們可以與外部的主機進行交互。當您為您的容器中或使用鏈路指定公共端口則IP通信允許容器之間。他們可以互相ping通，發送/接收UDP數據包，并建立TCP連接，但可以在必要時會受到限制。從一個網絡架構來看，給定Docker主機上的所有容器都坐在橋接接口。這意味著，他們只是想通過一個普通的以太網交換機連接的物理機器，不會多，不會少。

代碼是如何成熟提供內核命名空間和專用網絡？內核命名空間的內核版本2.6.15和2.6.26之間進行了介紹。這意味著，自2008年7月（2.6.26發布日期，現在5年前），命名空間代碼已經實行和審查上有大量的生產系統。還有更多：設計靈感的命名空間代碼，甚至更老。命名空間實際上是為了重新實現的，因為它們可能被主流內核內合并這樣的方式的OpenVZ的特性。OpenVZ的最初發布于2005年，所以在設計和執行都相當成熟。

控制組 cgroups

控制組是Linux的容器的另一重要組成部分。他們實行資源核算和限制。他們提供了很多非常有用的指標，但他們也有助于確保每個容器獲得其公平的內存，CPU，磁盤共享I/O;并且，更重要的是，一個單一的容器不能用盡這些資源中的一個而使系統癱瘓。

因此，盡管它們不起到防止一個容器訪問或影響數據和另一個容器的進程的作用，它們是必不可少的，以抵擋拒絕服務的一些攻擊。他們是在多租戶平臺，像公共和私有PaaS尤為重要，以保證正常運行時間一致（和性能），即使一些應用開始胡作非為。

控制組已經存在了一段時間，以及：代碼在2006年已經開始，并在內核2.6.24開始合并。

二、Docker守護攻擊面

運行容器（和應用程序）與Docker意味著運行Docker守護進程。此守護進程目前需要root權限，因此，你應該知道的一些重要的細節。

首先，只有受信任的用戶應該可以控制你的Docker守護進程。這是直接造成一些強大的Docker功能。具體來說，Docker可以讓你分享的Docker主體和客體容器之間的目錄;它允許你這樣做不限制容器的訪問權限。這意味著，你可以開始一個容器，其中/host目錄將是你的主機上的/目錄下;并且容器將能夠改變你的主機文件系統沒有任何限制。這聽起來很瘋狂？好吧，你要知道，所有的虛擬化系統允許文件系統資源共享的行為方式相同。沒有什么能阻止你從一個虛擬機共享您的根文件系統（甚至是你的root塊設備）。

這具有很強的安全性含義：例如，如果從通過API的Web服務器來提供容器中工具Docker，你應該比平常使用參數檢查多加小心，以確保惡意用戶無法通過精雕細琢的參數引起Docker創建任意容器。

出于這個原因，所述的REST API端點（所使用的DockerCLI與Docker守護程序進行通信）中Docker0.5.2改變，現在采用的是UNIX套接字代替結合在127.0.0.1 TCP套接字（后者是容易跨站點腳本攻擊，如果你碰巧直接在本地計算機上運行Docker，一個VM之外）。然后，您可以使用傳統的UNIX權限檢查限制訪問控制套接字。

您也可以通過暴露在HTTP REST API，如果你明確決定等。但是，如果你這樣做，意識到上述的安全含義，你應該確保它會到達只能從一個可信任的網絡或VPN;或受保護的如與安全通道和客戶端的SSL證書。你也可以保證他們HTTPS和證書。

在Linux的命名空間中的最新改進將很快允許沒有root權限運行全功能的容器中，這要歸功于新的用戶空間。這是覆蓋在這里詳細。此外，這將解決由共享主機和客戶之間的文件系統的問題，因為用戶命名空間允許容器（包括root用戶）內的用戶被映射到在主機系統的其他用戶。

因此，最終目標是Docker要實現兩個額外的安全性改進：

• 映射容器的root用戶的Docker主機的非root用戶，以減少容器到主機的權限提升的效果;
• 允許docker守護程序沒有root權限運行，并委托操作要求這些特權以及審計的子流程，每個都有自己的（非常有限）適用范圍：虛擬網絡設置，文件系統管理，等等。

最后，如果在服務器上運行Docker，建議以在服務器上運行專門Docker，并且通過Docker控制容器中內移動的所有其他服務。當然，這是好的，讓您最喜歡的管理工具（可能至少SSH服務器），以及現有的監測/監控過程（例如，NRPE，collectd等）。

三、內核安全特性和何與容器中互動

Linux內核能力 Capabilities

默認情況下，Docker開始容器具有非常有限的功能集。這意味著什么？

功能打開二進制“root/非root”二分法成細粒度的訪問控制系統。進程（如Web服務器），僅僅需要綁定低于1024的端口上沒有以root身份運行：他們可以被授予net_bind_service能力來代替。而且還有很多其他功能，幾乎所有的地方，通常都需要root權限的具體領域。

這意味著許多為docker的安全;讓我們來看看為什么！

一般的服務器（裸機或虛擬機）都需要運行一堆流程作為root。這些通常包括SSH，cron，syslogd;硬件管理工具（如加載模塊），網絡配置工具（如處理DHCP，WPA或VPN）的，等等。容器是非常不同的，因為幾乎所有的這些任務由容器周圍的基礎設施進行處理：

• SSH訪問通常由Docker主機運行的單個服務器進行管理;
• cron，必要的時候，應該運行作為一個用戶進程，敬業，專為需要它的調度服務，而不是作為一個平臺性的設備應用程序;
• 日志管理層也通常會被交給Docker，或由第三方服務，如Loggly或Splunk的;
• 硬件管理是無關緊要的，這意味著你永遠不需要容器中運行udevd會或同等守護進程;
• 網絡管理發生在容器外，執行的盡可能多的分離關注點，這意味著容器不應該需要執行ifconfig，route，或IP命令（除了當一個容器是專為像一個路由器或防火墻，當然）。

這意味著，在大多數情況下，容器將不會在所有需要的“真實”root特權。因此，容器可以使用減少的能力集運行;這意味著“root”在一個容器內具有比真正的“root”少得多特權。例如，它是可能的：

• 拒絕所有“裝載”操作;
• 拒絕訪問原始套接字（防止數據包欺騙）;
• 拒絕訪問某些文件系統操作，如創建新的設備節點，改變文件的所有者，或者改變屬性（包括不可變標志）;
• 拒絕模塊加載;
• 以及等等。

這意味著，即使入侵者設法升級到root的容器內，這將是非常困難做嚴重損壞，或升級到主機。

這不會影響常規的網絡應用;但惡意的用戶會發現，兵工廠在他們的處置大幅下降！默認情況下，Docker滴除了那些需要的，白名單，而不是黑名單的方式全部功能。你可以看到在Linux中提供聯機幫助功能的完整列表。

當然，你可以隨時啟用額外的功能，如果你真的需要它們（舉例來說，如果你想使用FUSE為基礎的文件系統），但默認情況下，Docker容器使用默認的核心能力，只有白名單。

其他內核安全特性

Capabilities 能力是現代Linux內核提供了許多安全特性之一。另外，也可以利用現有的，公知的系統，如TOMOYO，AppArmor，SELinux，GRSEC等使用Docker。

而Docker目前只允許功能，它不干擾其它系統。這意味著，有許多不同的方式來加固Docker主機。下面是一些例子。

• 您可以運行GRSEC和PAX內核。這將增加很多安全檢查，無論是在編譯時和運行時;它也將打敗很多漏洞，這要歸功于像地址隨機化技術。它不需要Docker特定的配置中，由于這些安全功能適用全系統，獨立的容器中。
• 如果你的發行版自帶的Docker容器安全模型模板，你可以使用它們的開箱即用。舉例來說，推出一個與AppArmor工作和Red Hat自帶SELinux策略Docker的模板。這些模板提供了一個額外的安全網（即使它大大重疊使用能力）。
• 您可以使用自己喜歡的訪問控制機制，定義自己的策略。

就像有許多第三方工具來增強Docker容器如特殊的網絡拓撲結構或共享文件系統，你可以期望看到的工具來強化現有的Docker容器，而不會影響Docker的核心。

結論

Docker容器，默認情況下，相當安全的;特別是如果你把你的運行進程容器非特權用戶內部的護理（即非root）。

您可以通過啟用AppArmor中，SELinux，GRSEC，或者你最喜歡的加固解決方案中添加額外的安全層。

最后但并非最不重要的，如果你看到在其他容器化系統，有趣的安全功能，您將能夠實現它們，以及使用Docker，因為一切無論如何都是由內核提供。

譯自Docker官方文檔：https://docs.docker.com/articles/security/

原文出自:http://blog.csdn.net/yangzhenping/article/details/41721073