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

[[162909]]

要安全地使用Docker方案，大家首先需要了解其面對的潛在安全問題，并掌握能夠?qū)谌萜髦到y(tǒng)加以切實保護的各類主要工具與技術(shù)。

大家還需要隨時牢記以下五個問題，并在利用Docker承載關(guān)鍵性任務(wù)應(yīng)用程序的整個流程當中秉承這種謹慎的態(tài)度。

內(nèi)核漏洞

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

拒絕服務(wù)攻擊

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

容器突破

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

含毒鏡像

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

違規(guī)之秘

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