安全似乎落后于Docker陣營在其他方面的發(fā)展步伐。雖然越來越多的企業(yè)在數(shù)據(jù)中心使用Docker,但管理員們用來保護容器的技術(shù)卻完全是慢慢站穩(wěn)腳跟。在許多情況下,正是當(dāng)初讓Docker大受歡迎的功能特性恰恰也暴露了安全漏洞(見圖1)。
圖1:Docker網(wǎng)站稱贊其容器是即刻奏效的解決方案。
什么是沒有隔離的內(nèi)核?
Docker依賴Linux內(nèi)核的功能:建立相互隔離的環(huán)境(應(yīng)用程序在里面運行)。這些容器很精簡,因為它們共享同一內(nèi)核,卻在不同的運行時環(huán)境中執(zhí)行,這歸功于控制組(cgroup)和命名空間,它們定義了容器可以使用哪些資源。與此同時,容器本身只能看到某些進程和網(wǎng)絡(luò)功能。
雖然攻擊者難以從一個被劫持的虛擬機與主機的內(nèi)核進行交互,但容器隔離并不提供同樣的防御。除了/sys和/proc外,攻擊者還照樣可以進入內(nèi)核的關(guān)鍵子系統(tǒng),比如SELinux和控制組,這意味著攻擊者有可能避開主機的安全功能特性。與此同時,容器使用與主機系統(tǒng)同樣的用戶命名空間。換句話說,如果進程以根權(quán)限在容器中運行,它與內(nèi)核或掛載的文件系統(tǒng)交互時,保留這些權(quán)限。因而,管理員還是別以根權(quán)限在容器中運行軟件為妙;實際上,很少需要這樣。
風(fēng)險:Docker的守護進程
然而,Docker守護進程需要根權(quán)限。它管理主機上的容器,需要與提供隔離環(huán)境的內(nèi)核進行對話。與守護進程進行交互的用戶因而被授予了訪問系統(tǒng)的權(quán)限。如果主機托管服務(wù)提供商通過Web界面將容器作為一個自助服務(wù)選項來提供,這種情形會來得尤其嚴重。
雖然使用docker群組是個辦法,但不太可能改善安全,因為群組成員可以構(gòu)建容器;而在容器中,首先可以運行根外殼,其次可以掛載主機的根文件系統(tǒng)。這里的唯一辦法就是,嚴格監(jiān)管對Docker服務(wù)的訪問,避免不需要的權(quán)限升級。
此外,Docker的守護進程可以通過HTTP(S),借助REST API進行聯(lián)系。如果你使用這項功能,就需要限制只由可信賴網(wǎng)絡(luò)才可以訪問API,或者通過SSL客戶端證書或之類的機制來限制訪問。
對策
新版本的Docker隨帶減小上述攻擊場景帶來的影響的功能特性。Docker以只讀方式掛載/sys文件系統(tǒng)和/proc中的重要文件。容器無法寫入到它們,因而防止容器中的權(quán)限進程操縱主機系統(tǒng)。
內(nèi)核將根權(quán)限細分成了幾項功能,然后將這些功能逐個分配給了進程。默認情況下,Docker阻止重要功能,防止容器中的權(quán)限進程為非作歹。這些功能包括網(wǎng)絡(luò)配置、裝入內(nèi)核模塊的功能或者訪問音頻子系統(tǒng)。如果某個特殊的應(yīng)用程序需要被阻止的功能,Docker允許這些功能供某個容器使用。
SELinux局限性
SELinux是一種安全框架,它給每個文件和每個進程分配了多部分標簽(multipart label)。策略定義了哪個進程標簽可以訪問哪個文件標簽。Docker支持兩個變種:類型強制(type enforcement)和多類別安全(MCS)。
類型強制限制了容器對主機文件系統(tǒng)的訪問。所有容器進程都以同一種類型來運行,這樣就可以訪問容器中的文件和許多主機系統(tǒng)文件,但是又可以防止訪問主機上的大多數(shù)文件夾(即/var、/root和/home)。
如果只使用類型強制,容器就能夠輕松訪問其他容器中的數(shù)據(jù)。歸功于MCS,容器啟動時,SELinux為容器分配了隨機的MCS標簽;Docker守護進程用這個標簽標記容器中的所有文件,而內(nèi)核可防止使用不同MCS標簽的進程訪問容器中的文件。
在許多企業(yè),SELinux已被認為是一項不需要的功能特性,也是管理員們喜歡禁用的一項特性。然而,Docker容器的安全依賴安全虛擬化(sVirt)之類的功能特性。在幾乎沒有其他應(yīng)用程序幫助的情況下,單單sVirt就足以防止來自其他容器的用戶讀取你的文件。
未來
就未來而言,Docker開發(fā)人員在計劃增強容器的安全性和隔離性。三項功能特性會助一臂之力,包括用戶命名空間、Seccomp,以及基于角色的訪問控制(RBAC),加強對Docker守護進程的訪問。
用戶命名空間獲得了優(yōu)先權(quán)。Docker將來自容器的用戶ID與其他主機的ID對應(yīng)起來。其想法是大大限制攻擊屬于根目錄的文件的能力。
由于所有容器都與同一個內(nèi)核對話,內(nèi)核功能方面的一個錯誤對主機和容器之間的邊界以及對容器本身之間的邊界來說都是致命的。來自谷歌的Seccomp可防止進程對特定系統(tǒng)調(diào)用的訪問。雖然進程使用系統(tǒng)調(diào)用來訪問內(nèi)核,但在600個可用調(diào)用中大多數(shù)很少用到。要是沒有這些調(diào)用,有望減小潛在的攻擊面。Daniel Walsh在紅帽公司從事容器安全工作。他認為,開發(fā)人員有望將可調(diào)用系統(tǒng)調(diào)用的數(shù)量最多減少50%。
此外,開發(fā)人員在期望完善對Docker服務(wù)的訪問,補充驗證選項。這么做意味著,并沒有根授權(quán)以訪問主機的用戶可以使用這項服務(wù)。如果開發(fā)人員另外引入RBAC,Docker管理員就能為用戶分配不同的角色,因而為他們提供與守護進程進行交互的受限制權(quán)限。在這些方案的幫助下,應(yīng)該可以在未來進一步限制對容器或功能的訪問。
結(jié)束語
Docker開發(fā)人員已經(jīng)在許多方面積極響應(yīng),加強容器的安全,他們在繼續(xù)添加新的功能特性,保持這個勢頭。最近為版本1.8中的Docker映像推出了一種驗證系統(tǒng),那就是內(nèi)容信任(Content Trust)。此外,開放容器計劃(Open Container Initiative)正考慮將更多的精力投入到安全方面上。
未來仍需要做大量工作。比如說,需要定義容器管理方面可持續(xù)的最佳實踐,以促進容器在企業(yè)得到更廣泛的使用。
原文標題:Improving Docker security now and in the future
分享到微信 ×
打開微信,點擊底部的“發(fā)現(xiàn)”,
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。