對於Docker使用的一些安全配置建議

 　　介紹

　　相信很多開發者都默認Docker這樣的容器是一種沙盒(sandbox)應用，也就是說他們可以用root權限在Docker中運行隨便什麼應用，而Docker有安全機制能保護宿主系統。比如，有些人覺得Docker容器裡面的進程跟虛擬機裡面的進程一樣安全;還有的人隨便找個源就下載沒有驗證過的Docker鏡像，看都不看內容就在宿主機器上嘗試、學習和研究;還有一些提供PaaS服務的公司竟然允許用戶向多租戶系統中提交自己定制的Docker鏡像。請注意，上述行為均是不安全的。

　　本文將介紹Docker的隔離性和安全性，以及為什麼它在隔離和安全性上不如傳統的虛擬機。

　　何謂安全性?

　　單單就Docker來說，安全性可以概括為兩點：

　　不會對主機造成影響

　　不會對其他容器造成影響

　　所以安全性問題90%以上可以歸結為隔離性問題。而Docker的安全問題本質上就是容器技術的安全性問題，這包括共用內核問題以及Namespace還不夠完善的限制：

　　/proc、/sys等未完全隔離

　　Top, free, iostat等命令展示的信息未隔離

　　Root用戶未隔離

　　/dev設備未隔離

　　內核模塊未隔離

　　SELinux、time、syslog等所有現有Namespace之外的信息都未隔離

　　當然，鏡像本身不安全也會導致安全性問題。

　　真的不如虛擬機安全?

　　其實傳統虛擬機系統也絕非100%安全，只需攻破Hypervisor便足以令整個虛擬機毀於一旦，問題是有誰能隨隨便便就攻破嗎?如上所述，Docker的隔離性主要運用Namespace 技術。傳統上Linux中的PID是唯一且獨立的，在正常情況下，用戶不會看見重復的PID。然而在Docker采用了Namespace，從而令相同的PID可於不同的Namespace中獨立存在。舉個例子，A Container 之中PID=1是A程序，而B Container之中的PID=1同樣可以是A程序。雖然Docker可透過Namespace的方式分隔出看似是獨立的空間，然而Linux內核(Kernel)卻不能Namespace，所以即使有多個Container，所有的system call其實都是通過主機的內核處理，這便為Docker留下了不可否認的安全問題。

　　傳統的虛擬機同樣地很多操作都需要通過內核處理，但這只是虛擬機的內核，並非宿主主機內核。因此萬一出現問題時，最多只影響到虛擬系統本身。當然你可以說黑客可以先Hack虛擬機的內核，然後再找尋Hypervisor的漏洞同時不能被發現，之後再攻破SELinux，然後向主機內核發動攻擊。文字表達起來都嫌繁復，更何況實際執行?所以Docker是很好用，但在遷移業務系統至其上時，請務必注意安全性!

　　如何解決?

　　在接納了“容器並不是全封閉”這種思想以後，開源社區尤其是紅帽公司，連同Docker一起改進Docker的安全性，改進項主要包括保護宿主不受容器內部運行進程的入侵、防止容器之間相互破壞。開源社區在解決Docker安全性問題上的努力包括：

　　Audit namespace

　　作用：隔離審計功能

　　未合入原因：意義不大，而且會增加audit的復雜度，難以維護。

　　Syslognamespace

　　作用：隔離系統日志

　　未合入原因：很難完美的區分哪些log應該屬於某個container。

　　Device namespace

　　作用：隔離設備(支持設備同時在多個容器中使用)

　　未合入原因：幾乎要修改所有驅動，改動太大。

　　Time namespace

　　作用：使每個容器有自己的系統時間

　　未合入原因：一些設計細節上未達成一致，而且感覺應用場景不多。

　　Task count cgroup

　　作用：限制cgroup中的進程數，可以解決fork bomb的問題

　　未合入原因：不太必要，增加了復雜性，kmemlimit可以實現類似的效果。(最近可能會被合入)

　　隔離/proc/meminfo的信息顯示

　　作用：在容器中看到屬於自己的meminfo信息

　　未合入原因：cgroupfs已經導出了所有信息，/proc展現的工作可以由用戶態實現，比如fuse。

　　不過，從08年cgroup/ns基本成型後，至今還沒有新的namespace加入內核，cgroup在子系統上做了簡單的補充，多數工作都是對原有subsystem的完善。內核社區對容器技術要求的隔離性，本的原則是夠用就好，不能把內核搞的太復雜。

　　一些企業也做了很多工作，比如一些項目團隊采用了層疊式的安全機制，這些可選的安全機制具體如下：

　　1、文件系統級防護

　　文件系統只讀：有些Linux系統的內核文件系統必須要mount到容器環境裡，否則容器裡的進程就會罷工。這給惡意進程非常大的便利，但是大部分運行在容器裡的App其實並不需要向文件系統寫入數據。基於這種情況，開發者可以在mount時使用只讀模式。比如下面幾個： /sys 、/proc/sys 、/proc/sysrq-trigger 、 /proc/irq、/proc/bus

　　寫入時復制(Copy-On-Write)：Docker采用的就是這樣的文件系統。所有運行的容器可以先共享一個基本文件系統鏡像，一旦需要向文件系統寫數據，就引導它寫到與該容器相關的另一個特定文件系統中。這樣的機制避免了一個容器看到另一個容器的數據，而且容器也無法通過修改文件系統的內容來影響其他容器。

　　2、Capability機制

　　Linux對Capability機制闡述的還是比較清楚的，即為了進行權限檢查，傳統的UNIX對進程實現了兩種不同的歸類，高權限進程(用戶ID為0，超級用戶或者root)，以及低權限進程(UID不為0的)。高權限進程完全避免了各種權限檢查，而低權限進程則要接受所有權限檢查，會被檢查如UID、GID和組清單是否有效。從2.2內核開始，Linux把原來和超級用戶相關的高級權限劃分成為不同的單元，稱為Capability，這樣就可以獨立對特定的Capability進行使能或禁止。通常來講，不合理的禁止Capability，會導致應用崩潰，因此對於Docker這樣的容器，既要安全，又要保證其可用性。開發者需要從功能性、可用性以及安全性多方面綜合權衡Capability的設置。目前Docker安裝時默認開啟的Capability列表一直是開發社區爭議的焦點，作為普通開發者，可以通過命令行來改變其默認設置。

　　3、NameSpace機制

　　Docker提供的一些命名空間也從某種程度上提供了安全保護，比如PID命名空間，它會將全部未運行在開發者當前容器裡的進程隱藏。如果惡意程序看都看不見這些進程，攻擊起來應該也會麻煩一些。另外，如果開發者終止pid是1的進程命名空間，容器裡面所有的進程就會被全部自動終止，這意味著管理員可以非常容易地關掉容器。此外還有網絡命名空間，方便管理員通過路由規則和iptable來構建容器的網絡環境，這樣容器內部的進程就只能使用管理員許可的特定網絡。如只能訪問公網的、只能訪問本地的和兩個容器之間用於過濾內容的容器。

　　4、Cgroups機制

　　主要是針對拒絕服務攻擊。惡意進程會通過占有系統全部資源來進行系統攻擊。Cgroups機制可以避免這種情況的發生，如CPU的cgroups可以在一個Docker容器試圖破壞CPU的時候登錄並制止惡意進程。管理員需要設計更多的cgroups，用於控制那些打開過多文件或者過多子進程等資源的進程。

　　5、SELinux

　　SELinux是一個標簽系統，進程有標簽，每個文件、目錄、系統對象都有標簽。SELinux通過撰寫標簽進程和標簽對象之間訪問規則來進行安全保護。它實現的是一種叫做MAC(Mandatory Access Control)的系統，即對象的所有者不能控制別人訪問對象。

　　安全建議

　　最簡單的就是不要把Docker容器當成可以完全替代虛擬機的東西。跑在Docker容器中的應用在很長一段時間內都將會是選擇性的，通常只跑測試系統或可信業務。

　　門檻再高一點，我們對系統做減法，通過各種限制來達到安全性。這也是最主流的、有效的安全加固方法，比如上一章節介紹的幾種安全機制。同時一定要保證內核的安全和穩定。外部工具的監控、容錯等系統也必不可少。

　　總之通過適配、加固的Docker容器方案，在安全性上完全可以達到商用標准。就是可能對實施人員的技術要求和門檻較高。