虚拟化容器Docker的安全性讨论
一．Docker所采用的安全機制分析
評估 Docker 的安全性時，主要考慮三個方面:
由內核的名字空間和控制組機制提供的容器內在安全
Docker程序（特別是服務端）本身的抗***性
內核安全性的加強機制對容器安全性的影響
1.內核名字空間
Docker 容器和 LXC 容器很相似，所提供的安全特性也差不多。當用 docker run 啟動一個容器時，在后臺 Docker 為容器創(chuàng)建了一個獨立的名字空間和控制組集合。
名字空間提供了最基礎也是最直接的隔離，在容器中運行的進程不會被運行在主機上的進程和其它容器發(fā)現(xiàn)和作用。
每個容器都有自己獨有的網(wǎng)絡棧，意味著它們不能訪問其他容器的 sockets 或接口。不過，如果主機系統(tǒng)上做了相應的設置，容器可以像跟主機交互一樣的和其他容器交互。當指定公共端口或使用 links 來連接 2 個容器時，容器就可以相互通信了（可以根據(jù)配置來限制通信的策略）。
從網(wǎng)絡架構的角度來看，所有的容器通過本地主機的網(wǎng)橋接口相互通信，就像物理機器通過物理交換機通信一樣。
那么，內核中實現(xiàn)名字空間和私有網(wǎng)絡的代碼是否足夠成熟？
內核名字空間從 2.6.15 版本（2008 年 7 月發(fā)布）之后被引入，數(shù)年間，這些機制的可靠性在諸多大型生產系統(tǒng)中被實踐驗證。
實際上，名字空間的想法和設計提出的時間要更早，最初是為了在內核中引入一種機制來實現(xiàn) OpenVZ 的特性。而 OpenVZ 項目早在 2005 年就發(fā)布了，其設計和實現(xiàn)都已經(jīng)十分成熟。
普通虛擬機將整個操作系統(tǒng)運行在虛擬的硬件平臺上, 進而提供完整的運行環(huán)境供應用程序運行, 而Docker則直接在宿主平臺上加載運行應用程序.本質上他在底層使用LXC啟動一個Linux Container,通過cgroup等機制對不同的container內運行的應用程序進行隔離,權限管理和quota分配等。每個container擁有自己獨立的各種命名空間(亦即資源)包括: PID 進程, MNT 文件系統(tǒng), NET 網(wǎng)絡, IPC , UTS 主機名等
2.控制組
控制組是 Linux 容器機制的另外一個關鍵組件，負責實現(xiàn)資源的審計和限制。
它提供了很多有用的特性；以及確保各個容器可以公平地分享主機的內存、CPU、磁盤 IO 等資源；當然，更重要的是，控制組確保了當容器內的資源使用產生壓力時不會連累主機系統(tǒng)。
盡管控制組不負責隔離容器之間相互訪問、處理數(shù)據(jù)和進程，它在防止拒絕服務（DDOS）***方面是必不可少的。尤其是在多用戶的平臺（比如公有或私有的 PaaS）上，控制組十分重要。例如，當某些應用程序表現(xiàn)異常的時候，可以保證一致地正常運行和性能。
控制組機制始于 2006 年，內核從 2.6.24 版本開始被引入。
3.Docker服務端的防護
運行一個容器或應用程序的核心是通過 Docker 服務端。Docker 服務的運行目前需要 root 權限，因此其安全性十分關鍵。
首先，確保只有可信的用戶才可以訪問 Docker 服務。Docker 允許用戶在主機和容器間共享文件夾，同時不需要限制容器的訪問權限，這就容易讓容器突破資源限制。例如，惡意用戶啟動容器的時候將主機的根目錄/映射到容器的 /host 目錄中，那么容器理論上就可以對主機的文件系統(tǒng)進行任意修改了。這聽起來很瘋狂？但是事實上幾乎所有虛擬化系統(tǒng)都允許類似的資源共享，而沒法禁止用戶共享主機根文件系統(tǒng)到虛擬機系統(tǒng)。
這將會造成很嚴重的安全后果。因此，當提供容器創(chuàng)建服務時（例如通過一個 web 服務器），要更加注意進行參數(shù)的安全檢查，防止惡意的用戶用特定參數(shù)來創(chuàng)建一些破壞性的容器
為了加強對服務端的保護，Docker 的 REST API（客戶端用來跟服務端通信）在 0.5.2 之后使用本地的 Unix 套接字機制替代了原先綁定在 127.0.0.1 上的 TCP 套接字，因為后者容易遭受跨站腳本***。現(xiàn)在用戶使用 Unix 權限檢查來加強套接字的訪問安全。
用戶仍可以利用 HTTP 提供 REST API 訪問。建議使用安全機制，確保只有可信的網(wǎng)絡或 ×××，或證書保護機制（例如受保護的 stunnel 和 ssl 認證）下的訪問可以進行。此外，還可以使用 HTTPS 和證書來加強保護。
最近改進的 Linux 名字空間機制將可以實現(xiàn)使用非 root 用戶來運行全功能的容器。這將從根本上解決了容器和主機之間共享文件系統(tǒng)而引起的安全問題。
終極目標是改進 2 個重要的安全特性：
將容器的 root 用戶映射到本地主機上的非 root 用戶，減輕容器和主機之間因權限提升而引起的安全問題；
允許 Docker 服務端在非 root 權限下運行，利用安全可靠的子進程來代理執(zhí)行需要特權權限的操作。這些子進程將只允許在限定范圍內進行操作，例如僅僅負責虛擬網(wǎng)絡設定或文件系統(tǒng)管理、配置操作等。
最后，建議采用專用的服務器來運行 Docker 和相關的管理服務（例如管理服務比如 ssh 監(jiān)控和進程監(jiān)控、管理工具 nrpe、collectd 等）。其它的業(yè)務服務都放到容器中去運行。
4.內核能力機制
能力機制（Capability）是 Linux 內核一個強大的特性，可以提供細粒度的權限訪問控制。 Linux 內核自 2.2 版本起就支持能力機制，它將權限劃分為更加細粒度的操作能力，既可以作用在進程上，也可以作用在文件上。
例如，一個 Web 服務進程只需要綁定一個低于 1024 的端口的權限，并不需要 root 權限。那么它只需要被授權 net_bind_service 能力即可。此外，還有很多其他的類似能力來避免進程獲取 root 權限。
默認情況下，Docker 啟動的容器被嚴格限制只允許使用內核的一部分能力。
使用能力機制對加強 Docker 容器的安全有很多好處。通常，在服務器上會運行一堆需要特權權限的進程，包括有 ssh、cron、syslogd、硬件管理工具模塊（例如負載模塊）、網(wǎng)絡配置工具等等。容器跟這些進程是不同的，因為幾乎所有的特權進程都由容器以外的支持系統(tǒng)來進行管理。
ssh 訪問被主機上ssh服務來管理；
cron 通常應該作為用戶進程執(zhí)行，權限交給使用它服務的應用來處理；
日志系統(tǒng)可由 Docker 或第三方服務管理；
硬件管理無關緊要，容器中也就無需執(zhí)行 udevd 以及類似服務；
網(wǎng)絡管理也都在主機上設置，除非特殊需求，容器不需要對網(wǎng)絡進行配置。
從上面的例子可以看出，大部分情況下，容器并不需要“真正的” root 權限，容器只需要少數(shù)的能力即可。為了加強安全，容器可以禁用一些沒必要的權限。
完全禁止任何 mount 操作；
禁止直接訪問本地主機的套接字；
禁止訪問一些文件系統(tǒng)的操作，比如創(chuàng)建新的設備、修改文件屬性等；
禁止模塊加載。
這樣，就算***者在容器中取得了 root 權限，也不能獲得本地主機的較高權限，能進行的破壞也有限。
默認情況下，Docker采用 白名單 機制，禁用 必需功能 之外的其它權限。當然，用戶也可以根據(jù)自身需求來為 Docker 容器啟用額外的權限。
5.其它安全特性
除了能力機制之外，還可以利用一些現(xiàn)有的安全機制來增強使用 Docker 的安全性，例如 TOMOYO, AppArmor, SELinux, GRSEC 等。
Docker 當前默認只啟用了能力機制。用戶可以采用多種方案來加強 Docker 主機的安全，例如：
在內核中啟用 GRSEC 和 PAX，這將增加很多編譯和運行時的安全檢查；通過地址隨機化避免惡意探測等。并且，啟用該特性不需要 Docker 進行任何配置。
使用一些有增強安全特性的容器模板，比如帶 AppArmor 的模板和 Redhat 帶 SELinux 策略的模板。這些模板提供了額外的安全特性。
用戶可以自定義訪問控制機制來定制安全策略。
跟其它添加到 Docker 容器的第三方工具一樣（比如網(wǎng)絡拓撲和文件系統(tǒng)共享），有很多類似的機制，在不改變 Docker 內核情況下就可以加固現(xiàn)有的容器。
6.總結
總體來看，Docker 容器還是十分安全的，特別是在容器內不使用 root 權限來運行進程的話。
另外，用戶可以使用現(xiàn)有工具，比如 Apparmor, SELinux, GRSEC 來增強安全性；甚至自己在內核中實現(xiàn)更復雜的安全機制。
二．Docker的安全隱患
1.能否徹底隔離
在超復雜的業(yè)務系統(tǒng)中，單OS到底能不能實現(xiàn)徹底隔離，一個程序的崩潰/內存溢出/高CPU占用到底會不會影響到其他容器或者整個系統(tǒng)?很多人對Docker能否在實際的多主機的生產環(huán)境中支持關鍵任務系統(tǒng)還有所懷疑。 注* 就像有人質疑Node.JS單線程快而不穩(wěn)，無法在復雜場景中應用一樣。
不過可喜的是，目前Linux內核已經(jīng)針對Container做了很多改進，以支持更好的隔離。
2.GO語言還沒有完全成熟
Docker由Go語言開發(fā)，但GO語言對大多數(shù)開發(fā)者來說比較陌生，而且還在不斷改進，距離成熟還有一段時間。此半git、半包管理的方式讓一些人產生不適。
3.被私有公司控制
Docker是一家叫Dotcloud的私有公司設計的，公司都是以營利為目的，比如你沒有辦法使用源代碼編繹Docker項目，只能使用黑匣子編出的Docker二進制發(fā)行包，未來可能不是完全免費的。 目前Docker已經(jīng)推出面向公司的企業(yè)級服務(咨詢、支持和培訓)。
4.Docker鏡像系統(tǒng)安全性討論
“本文作者深入研究了Docker鏡像的下載流程，并逐步分析了Docker鏡像下載過程中可能出現(xiàn)的安全問題。關注Docker安全以及做Docker鏡像存儲的同學必看。另外，作者還總結了應該采取哪些措施來改善Docker鏡像的安全性。”
最近在使用Docker下載一個“官方”容器鏡像時我看到這么一行提示：
ubuntu:14.04: The image you are pulling has been verified
我當時以為這和Docker極力推薦的鏡像簽名系統(tǒng)有關，所以并未深究。后來，在研究Docker鏡像安全相關的加密系統(tǒng)時，我開始進一步探索Docker的鏡像安全。而我發(fā)現(xiàn)所有與鏡像安全相關的邏輯完全是系統(tǒng)性的錯誤。
按照Docker的說法，下載的鏡像完全是基于簽名的manifest的存在而做出的，并且Docker并沒有從manifest中校驗鏡像的校驗和（checksum）。***者可以偽造提供一個具有簽名證明的鏡像，這個問題很容易被***者利用。
鏡像從HTTPS服務器上下載下來，然后通過Docker daemon的一個不安全的流處理管道：
[解壓縮] -> [tarsum] -> [解包]
這個管道很高效，但毫無安全可言。在未驗證簽名之前，管道不應該處理不受信任的輸入。然而，在驗證檢驗和之前，Docker進行了三次鏡像的處理。
盡管Docker做了聲明，但它從未實際檢查過鏡像校驗。下面是Docker中唯一一處與驗證鏡像校驗和有關的代碼，但是即便在鏡像中提供不匹配的校驗和，我也無法觸發(fā)這個警告。
if img.Checksum != "" && img.Checksum != checksum { log.Warnf("image layer checksum mismatch: computed %q, expected %q", checksum, img.Checksum) } 不安全的處理管道
解壓縮
Docker支持三種壓縮算法：gzip、bzip2和xz。前兩者使用Go的標準庫實現(xiàn)，這是內存安全的，所以我能想到的漏洞類型是拒絕服務***，如宕機、CPU和內存過度使用。
第三個壓縮算法xz更有趣。因為沒有原生的Go實現(xiàn)，Docker運行xz程序來解壓縮。
xz程序來自XZ Utils項目，它從接近2萬行C代碼中構建而來。C不是一個內存安全的語言。這意味著一個C程序的惡意輸入，此處為XZ Utils正在解包的Docker鏡像，有執(zhí)行任意的代碼的可能。
如果Docker以root運行xz，那會更糟糕，這意味著如果xz存在一個漏洞，執(zhí)行docker pull將嚴重危及你的整個系統(tǒng)。
Tarsum
tarsum的使用出于好意，但完全錯誤。為了取得一個任意編碼的tar文件的確定性校驗和，Docker對tar進行解碼然后以確定性順序對特定部分進行哈希，排除了其他部分。
因為這個處理過程是為了生成校驗和，它正在解碼的不受信任的數(shù)據(jù)可被設計成利用tarsum代碼的漏洞。這里可能的漏洞是拒絕服務***以及邏輯缺陷，這將引起文件在不改變校驗和的情況下被注入、跳過、使用不同方式處理、修改、添加等。
解包
解包分為tar解碼和將文件到保存到硬盤中兩個步驟，在編寫本文的時候已經(jīng)有解包階段的三個其他漏洞被報告出來，所以這也是非常危險的。
不應該存在未被檢驗的數(shù)據(jù)被解包到硬盤中的情況。
libtrust
libtrust是一個提供認證和權限控制的Docker包。但是官方?jīng)]有提供任何的規(guī)范，但它看起來像是實現(xiàn)了Javascript對象簽名與加密規(guī)范的一部分，以及其他不明算法。
所以在下載一個manifest簽名的以及使用libtrust驗證的鏡像時，會有如下不準確的提示：
ubuntu:14.04: The image you are pulling has been verified
目前只有Docker公司公布的“官方”鏡像manifest使用這個系統(tǒng)簽名，但從我參加的最近一次Docker管理咨詢委員會會議的討論看來，Docker公司計劃在未來更廣泛的部署它。目標應該是集中管理，由Docker公司控制一個發(fā)證機構用于鏡像和/或客戶證明簽名。
我曾在Docker代碼中查找簽名密鑰，但沒找到。看來密鑰并沒有嵌入到程序中。實際上，Docker后臺會在每次鏡像下載時通過HTTPS從CDN獲取密鑰。這是一個非常糟糕的方式，因為有很多種***可以導致受信任的密鑰被替換成惡意的。這種***包括但不限于：CDN供應商威脅、CDN供應密鑰源威脅以及客戶端下載密鑰時的中間人***。
補救
在完成此項研究之前，我已經(jīng)報告了我發(fā)現(xiàn)的tarsum系統(tǒng)的幾個問題，但至今沒有一個被修復。
我覺得必須采取一些措施來改善Docker鏡像下載系統(tǒng)的安全性：
棄用tarsum并實際驗證鏡像摘要
為安全起見，不應該使用tarsum。取而代之的是在進行任何處理前，將鏡像完全下載并對其加密簽名進行驗證。
增加權限隔離
涉及解壓縮或解包的鏡像處理步驟必須運行于具有最低限度的必要的權限的隔離的程序（容器？）中。不應該存在像xz這樣的解壓縮工具必須以root運行的情況。
更換libtrust
用The Update Framework替換libtrust，前者是明確設計用于解決軟件程序簽名的實際問題的。它的威脅模型非常全面，并且解決了很多l(xiāng)ibtrust沒有考慮到的事情。它擁有一個完整的規(guī)范，以及一個Python的參考實現(xiàn)，我已經(jīng)開始Go的實現(xiàn)并且歡迎任何人加入。
作為添加TUF到Docker的一部分，一個映射根密鑰到registry URL的本地密鑰庫將被加入，以便用戶可以使用不受Docker公司管理的自有簽名密鑰。
我想指出的是，一般情況下使用非Docker公司托管的registry用戶體驗非常差。在沒有任何技術原因的情況下，Docker公司似乎樂于將第三方registry降低為二等地位。這對一般的生態(tài)系統(tǒng)和最終用戶的安全來說都是個問題。綜合而言，針對第三方registry的分散的安全模型是必要和可取的。我非常期待Docker公司在重新設計他們的安全模型和鏡像驗證系統(tǒng)時考慮這一點。
結論
Docker用戶應該清楚負責下載鏡像的代碼是極其不安全的。用戶只能下載那些來源沒有問題的鏡像。目前，這不包括托管于Docker公司的“可信的”的鏡像，包括官方的Ubuntu和其他基礎鏡像。
最好的辦法是在本地阻止index.docker.io，并在鏡像導入到Docker之前手動使用docker load下載并檢驗鏡像。Red Hat的安全博客有篇與此相關的好文章。
原文：《Docker Image Insecurity》https://titanous.com/posts/docker-insecurity
譯文出自：http://dockerone.com/article/77
5.Docker中root權限安全隱患
Docker并不是虛擬機，Docker本來的用法也不是虛擬機。舉個簡單的例子，普通的虛擬機租戶root和宿主root是分開的，而Docker的租戶root和宿主root是同一個root。一旦容器內的用戶從普通用戶權限提升為root權限，他就直接具備了宿主機的root權限，進而可進行幾乎無限制的操作。這是為什么呢?因為Docker原本的用法是將進程之間進行隔離，為進程或進程組創(chuàng)建隔離開的運行空間，目的就是為了隔離有問題的應用，而進程之間的限制就是通過namespace和cgroup來進行隔離與配額限制。每一個隔離出來的進程組，對外就表現(xiàn)為一個container(容器)。在宿主機上可以看到全部的進程，每個容器內的進程實際上對宿主機來說是一個進程樹。也就是說，Docker是讓用戶自以為占據(jù)了全部的資源，從而給用戶一個“虛擬機”的感覺。
而且，Docker中可能會運行不受信任的應用程序。來源不明的應用程序，或者二進制代碼等等，以及有漏洞的應用程序，都可以稱為不受信任的應用程序。舉個例子，在Docker容器中只運行基礎的Apache服務器和MySQL數(shù)據(jù)庫，可能大家認為這樣的環(huán)境用root也沒問題，但是如果Apache或者MySQL有不為人所知的漏洞被利用，那么這兩個應用也就成為了不受信任的應用。因此，在以root運行應用程序或是在考慮安全環(huán)境的時候，需要以一切皆不可信的態(tài)度來對
6.Namespace的安全性
那么究竟是什么地方導致了Docker容器機制的安全問題呢？簡單一句話，Linux系統(tǒng)中不是所有東西都有命名空間（Namespace）。最新版本的Docker有五個命名空間：進程、網(wǎng)絡、掛載、宿主和共享內存。如此簡單的命名空間顯然無法給開發(fā)者提供復雜的安全保護。比如在類似KVM的環(huán)境里，虛擬機根本無法直接和宿主的內核交互，它沒有任何方式可以訪問內核文件系統(tǒng)中如/sys和/sys/fs這樣的地方。在這種情況下，想要脫離虛擬機來***宿主，比如要找到HyperVisor的弱點，攻克SELinux控制（這是個挺難的事情），然后才能夠染指宿主的文件系統(tǒng)。而在Docker這樣的容器里，原生就可以訪問宿主的內核，安全性從何而來？
Dan在文章中列舉了主流的沒有命名空間的內核，有：
?SELinux
?Cgroups
?file systems under?/sys
?/proc/sys,?/proc/sysrq-trigger,?/proc/irq,?/proc/bus
沒有命名空間的設備有：
?/dev/mem
?/dev/sd* file system devices
?Kernel Modules
如果開發(fā)者能訪問或者***任何一個，就可以獲得整個系統(tǒng)的控制權。
三．Docker安全性加固
文件系統(tǒng)只讀：有些Linux系統(tǒng)的內核文件系統(tǒng)必須要mount到容器環(huán)境里，否則容器里的進程就會罷工。這給惡意進程非常大的便利，但是大部分運行在容器里的App其實并不需要向文件系統(tǒng)寫入數(shù)據(jù)。基于這種情況，開發(fā)者可以在mount時使用只讀模式。比如下面幾個：
o. /sys
o. /proc/sys
o. /proc/sysrq-trigger
o. /proc/irq
o. /proc/bus
用只讀模式的好處是，那些在容器里權限比較高的進程也無法向宿主文件系統(tǒng)寫入。當然這里需要注意一點，必須要把這些進程remount可讀寫文件系統(tǒng)的能力給禁止。更進一步開發(fā)者甚至可以禁止容器mount任何文件系統(tǒng)，這需要通過使用capability完成，下面會詳細解釋。
寫入時復制：Copy-on-write的具體解釋請讀者參考前面的維基百科鏈接。Docker采用的就是這樣的文件系統(tǒng)。所有運行的容器可以先共享一個基本文件系統(tǒng)鏡像，一旦需要向文件系統(tǒng)寫數(shù)據(jù)，就引導它寫到與該容器相關的另一個特定文件系統(tǒng)中。這樣的機制避免了一個容器看到另一個容器的數(shù)據(jù)，而且容器也無法通過修改文件系統(tǒng)的內容來影響其他容器。
Linux對Capability機制闡述的還是比較清楚的，即為了進行權限檢查，傳統(tǒng)的UNIX對進程實現(xiàn)了兩種不同的歸類，高權限進程（用戶ID為0，超級用戶或者root），以及低權限進程（UID不為0的）。高權限進程完全避免了各種權限檢查，而低權限進程則要接受所有權限檢查，會被檢查如UID、GID和組清單是否有效。從2.2內核開始，Linux把原來和超級用戶相關的高級權限劃分成為不同的單元，稱為Capability，這樣就可以獨立對特定的Capability進行使能或禁止。
通常來講，不合理的禁止Capability，會導致應用崩潰，因此對于Docker這樣的容器，既要安全，又要保證其可用性。開發(fā)者需要從功能性、可用性以及安全性多方面綜合權衡Capability的設置。Dan在文中給出了Docker現(xiàn)有的Capability清單：chown、 dac_override、 fowner、 kill、 setgid、 setuid、 setpcap、 net_bind_service、 net_raw、 sys_chroot、 mknod、 setfcap 以及 audit_write。目前Docker安裝時默認開啟的Capability列表一直是開發(fā)社區(qū)爭議的焦點，作為普通開發(fā)者，可以通過命令行來改變其默認設置。熟悉Linux內核的讀者會發(fā)現(xiàn)，Docker提供的Capability是相對較少的。Dan在文中給出了Docker移除的Capability列表，并以CAP_NET_ADMIN為例，強調容器的設計應該是啟動時配置好網(wǎng)絡，而非從其內部修改，解釋了容器安全性和Capability的 權衡，感興趣的讀者可以深入閱讀。
Docker提供的一些命名空間也從某種程度上提供了安全保護，比如PID命名空間，它會將全部未運行在開發(fā)者當前容器里的進程隱藏。如果惡意程序看都看不見這些進程，***起來應該也會麻煩一些。另外，如果開發(fā)者終止pid是1的進程命名空間，容器里面所有的進程就會被全部自動終止，這意味著管理員可以非常容易地關掉容器。此外還有網(wǎng)絡命名空間，方便管理員通過路由規(guī)則和iptable來構建容器的網(wǎng)絡環(huán)境，這樣容器內部的進程就只能使用管理員許可的特定網(wǎng)絡。如只能訪問公網(wǎng)的、只能訪問本地的和兩個容器之間用于過濾內容的容器。
主要是針對拒絕服務***。惡意進程會通過占有系統(tǒng)全部資源來進行系統(tǒng)***。Cgroups機制可以避免這種情況的發(fā)生，如CPU的cgroups可以在一個Docker容器試圖破壞CPU的時候登錄并制止惡意進程。Dan表示，需要設計更多的cgroups，用于控制那些打開過多文件或者過多子進程等資源的進程。類似的在文中Dan還介紹了設備cgroups。
SELinux是一個標簽系統(tǒng)，進程有標簽，每個文件、目錄、系統(tǒng)對象都有標簽。SELinux通過撰寫標簽進程和標簽對象之間訪問規(guī)則來進行安全保護。它實現(xiàn)的是一種叫做MAC（Mandatory Access Control）的系統(tǒng)，即對象的所有者不能控制別人訪問對象。具體可以參見Dan的這篇文章。至于如何用SELinux來進行容器的安全防護，Infoq會有另一篇文章來詳細介紹Dan的思想。
總而言之，為了保證Docker容器的安全性，Dan的團隊嘗試了非常多的安全機制，但是正如之前一篇文章中講的，安全不在于機制的健全，而在于管理員自身的防范。在文章的結尾，Dan給出了管理員應該注意的一些事項，如只運行來自可信來源的應用，在安全防護比較好的宿主機上運行等等。
6.Docker安全要依靠其他的輔助機制
該作者還強調，如果堅持要root權限使用 Docker Engine ，系統(tǒng)的安全性可能會受到一系列眾所周知的內核安全漏洞的影響。因此特別建議：
· 在運行 Docker Engine 的系統(tǒng)中同時運行 AppArmor 或者 SELinux。
· 將機器分成不同的組，相互信任的容器劃在一組。
· 不要以 root 權限運行任何不受信任的應用程序。
在上述三條建議之上，還應該有一種機制，就是保障機制。要不停地輪序去檢測，要能夠發(fā)現(xiàn)可疑的行為，并且對任何可疑的行為要有反應。比如進程A并未給root權限，但是后來通過檢測機制發(fā)現(xiàn)它變成了root權限，我們就可以懷疑它是進行了非法提權的操作。也就是說，我們允許你逃逸，但是我們也能夠在最短的時間內發(fā)現(xiàn)你的逃逸行為，并且制止你。
此外，Docker在安全方面還存在亟待加固的幾點：login過程使用明文傳輸用戶名和密碼，Image分發(fā)認證、Docker對Host的逃逸(已公布的那個漏洞)、Docker內給租戶的root賬號能否提供、Docker的配額限制(磁盤、網(wǎng)絡)、Docker內萬一提權后的限制(SELinux/AppArmor/GRSecurity)、出入Docker流量的監(jiān)控和審計、AUFS存在的***點。
由于Docker需要把若干個container組或一個虛擬的私有內網(wǎng)，解決租戶之間的網(wǎng)絡隔離，但目前缺乏完整方案。從網(wǎng)絡性能來分析，現(xiàn)狀一般通過Docker Bridge或OVS實現(xiàn)NAT，用IPtable做隔離，性能堪憂，需要測試和驗證。也有同仁表示性能衰減在50%以上，因此性能衰減嚴重也就可能成為一個新的***平面。在網(wǎng)絡方面的***點存在container之間的嗅探、ARP***、IPtable的漏洞利用、對IPtable飽和***等等。
當然，絕大多數(shù)的Docker安全問題都是出現(xiàn)在被用于公有云[注]環(huán)境下的，如果Docker被使用在私有云[注]環(huán)境中，那么它所帶來的好處要遠遠多于其帶來的問題。
轉載于:https://blog.51cto.com/1362336072/2086703
總結
以上是生活随笔為你收集整理的虚拟化容器Docker的安全性讨论的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一文看懂如何搭建AI应用：10周学会深度
- 下一篇： ARVR编辑器V1.2.4曝光，原来好作