當前持續增長的云計算市場對虛擬化技術有著強烈的需求。遺憾的是，大多數的虛擬化解決方案不夠靈活，無法滿足研發需求，且使用全虛擬化解決方案的潛在開銷變成了制約基礎設施擴展性的負擔。

Docker讓開發和運維人員能無縫地部署容器，用于運行業務所需的應用與服務，從而減少這類開銷。然而，因為Docker與宿主系統使用同一內核，配置不當的容器將造成重大安全隱患。

Docker容器技術發展如火如荼，相關的安全技術也在不斷往前推進。從傳統的角度看，安全不單單是一個技術性的問題，更是一個意識的問題。在云時代，服務上云已經非常普遍。而安全滲透攻擊技術的自動化程度也到了很高水平，受攻擊的目標變多，同時攻擊者技術手段變高，使我們云端服務的安全環境變的不可預測。

當我們將容器技術應用到部署運維時，打包遷移都是圍繞Docker鏡像，這種方式避免了我們在復制運行環境時發生漂移。而在沒有處理慣例或者指引的情況下出現安全告警時，這種新的方式帶來了新的安全性挑戰。

傳統攻擊目標我們把它看成一個城池或城堡，容器是城池里的房間。傳統方式通過信息收集、漏洞發現、滲透入侵等階段進行系統滲透。

而從容器角度，從房間里邊探知里面的信息，這些信息跟城池本身有一定的關聯性或者是相似形，從而獲取整個系統結構的秘密。

在滲透行為進行的過程中，漏洞對于后續的入侵過程尤為重要。反過來，對企業來說如何及時發現和處理系統漏洞是服務安全的重要部分。

無論是哪種漏洞類型，總會有一個生效周期。產品發布后，滲透人員發現漏洞，到提交漏洞庫，或者0day無補丁漏洞。

廠商被通知或自行發現后進行補丁升級，然后是用戶升級，更新軟件或鏡像，最后修補完成。從滲透人員發現漏洞到廠商升級并發布補丁，這段時間屬于0day, 危害較大。

對應廠商升級，傳統方式和容器有些不同，傳統廠商，對相應服務維護升級比較及時，安全性較高。但對容器來說，限于基礎鏡像安全性，鏡像來源也不同，現階段對鏡像的維護升級水平也參差不齊，安全性不可預測。

我們需要看一下Docker本身的安全機制。Docker本身使用內核的安全機制，包括Capability，Namespace, Cgroups。而SELinux/AppArmor屬于訪問控制系列。

Docker并不是虛擬機，Docker本來的用法也不是虛擬機。舉個簡單的例子，普通的虛擬機租戶root和宿主root是分開的，而Docker的租戶root和宿主root是同一個root。一旦容器內的用戶從普通用戶權限提升為root權限，他就直接具備了宿主機的root權限，進而進行幾乎無限制的操作。

Capability用于限制容器所擁有的能力，也就是執行某些系統操作的權限，也可以根據需要對容器的能力進行增減。Namespace為每個容器提供隔離的系統運行環境。Cgroup主要用于對容器所使用的資源進行限制。技術措施上，對權限和資源進行限制，利用cgroup來為容器添加CPU和內存限制。

通過這些安全機制與參數設置，我們對Docker本身能有一個基本的安全操控。Docker社區也在為自身的安全不斷的努力。首先，在開源社區，為代碼貢獻者指定了代碼提交的指導原則，在開發過程中減少Bug和漏洞，提高產品質量。同時定期對產品進行滲透測試，及時審計安全漏洞。并開放了相應平臺，鼓勵安全滲透人員提交漏洞。官方也提供了檢測工具，專門為Docker的部署運行環境做安全風險初評。

除了上文中的具體安全設置，對于容器應用來說，策略上同樣是三方面來實施：1.定期滲透測試，安全審計;2. 盡量采用正規鏡像來源，相對于傳統安全，容器安全受質疑很大程度上是在于鏡像的維護及升級，因此在鏡像源頭保證安全和及時更新;3.及時升級容器服務，比如采用rollingupdate的方式對跑服務的容器進行升級等方式。

最后，雖然在安全上仍然存在問題，但我們看到，Docker在開源社區的關注度、活躍度很高，貢獻者也很多，大家群策群力，眾人拾柴的情況下，Docker容器技術的發展必然會越來越完善。存在的問題也會被逐步克服。

隨著這項技術逐漸被大眾接受并應用，云端容器應用逐漸會更廣泛，再加上滲透安全人員對Docker也慢慢熟悉，在未來一段時間內，Docker的安全問題會有一個集中突增的時間。但隨后Docker進步與升級，再加上鏡像安全機制的完善，安全問題也會隨之慢慢減少。