通過閱讀網上帖子以及瀏覽相關新聞，大家可能會產生一種先入為主的印象，即Docker天生安全性薄弱且尚不足以被直接引入生產環境。不過實際情況是，雖然我們需要對容器安全性加以高度關注，但只要使用得當，其完全可以成為一套遠優于單獨使用虛擬機或者裸機的安全、高效生產系統。

[[162909]]

要安全地使用Docker方案，大家首先需要了解其面對的潛在安全問題，并掌握能夠對基于容器之系統加以切實保護的各類主要工具與技術。

大家還需要隨時牢記以下五個問題，并在利用Docker承載關鍵性任務應用程序的整個流程當中秉承這種謹慎的態度。

內核漏洞

與虛擬機系統不同，全部容器及其主機使用的都是同一套共享內核，因此該內核中存在的任何安全漏洞都有可能造成巨大影響。如果某套容器系統導致內核崩潰，那么這反過來又會造成整臺主機上的全部容器毀于一旦。在虛擬機當中，情況則要好得多：攻擊者必須借道虛擬機內核與虛擬機管理程序之后，才有可能真正接觸到主機內核。

拒絕服務攻擊

所有容器都共享同樣的內核資源。如果某套容器能夠以獨占方式訪問某些資源——包括內存以及用戶ID等其它更為抽象化的資源——那么與其處于同一臺主機上的其它容器則很可能因資源匱乏而無法正常運轉。這正是拒絕服務攻擊(簡稱DoS)的產生原理，即合法用戶無法對部分或者全部系統進行訪問。

容器突破

能夠訪問某一容器的攻擊者在原則上應該無法借此訪問到其它容器或者主機。在默認情況下，用戶并不具備命名空間，因此游離于容器之外的任何進程都將在主機之上獲得與容器內相同的執行權限; 而如果大家在容器內擁有root權限，那么在主機上亦將具備root身份。這意味著大家需要對這種潛在的權限提升攻擊做好準備——這類攻擊意味著用戶往往通過應用程序代碼中需要配合額外權限的bug實現權限提升，從而使攻擊者獲得root或者其它級別的訪問與操縱能力?？紤]到容器技術目前仍處于早期發展階段，因此我們在規劃自己的安全體系時，必須要將這種容器突破狀況考慮在內。

含毒鏡像

那么我們要如何判斷自己使用的鏡像是否安全、是否存在篡改或者其宣稱的來源是否可靠?如果攻擊者誘導大家運行由其精心設計的鏡像，那么各位的主機與數據都將處于威脅之下。同樣的，大家還需要確保自己運行的鏡像為最新版本，且其中不包含任何存在已知安全漏洞的軟件版本。

違規之秘

當容器面向某數據庫或者服務發起訪問時，其往往需要某種秘密因素加以配合，例如API密鑰或者用戶名加密碼。能夠獲取這些秘密因素的攻擊者自然會將觸手伸向對應服務。這類問題在微服務架構當中往往更為嚴重，因為在此類環境內各容器會頻繁中止與啟動，因此受到的威脅遠高于一般而言運行周期更長且數據較少的虛擬機系統。我們今天并不會就此類問題的解決辦法展開探討，感興趣的朋友不妨查閱《Using Docker》(O’Reilly出版社，2015年)中的“Deployment”章節了解相關內容。