論文閱讀 Hypervisor- vs. Container-based Virtualization

ABSTRACT

很長一段時間以來，虛擬化這個術語都是指基於虛擬機監控程序的虛擬化。然而，在過去的幾年裏，基於容器的虛擬化變得成熟起來，特別是Docker得到了很多關注。基於管理程序的虛擬化爲完整的操作系統提供了強大的隔離，而基於容器的虛擬化則努力以很少的資源成本將進程與其他進程隔離開來。本文將區分hypervisor和基於容器的虛擬化，並描述Docker和LXC背後的機制。本文介紹了從容器框架上的簡單chroot到準備就緒的容器管理解決方案的過程，並介紹了容器的安全性。本文概述了兩種不同的虛擬化方法及其優缺點。

1 INTRODUCTION

本文比較了兩種不同的虛擬化方法:hypervisor和基於容器的虛擬化。Docker[1]是一種創建、管理和分發容器的免費工具，它通過將不同的技術結合到一個強大的虛擬化軟件中而得到了廣泛的關注。相比之下，基於虛擬機監控程序的虛擬化是被廣泛使用了幾十年的虛擬化領域的領軍人物。這兩種技術都有各自的優點，在決定哪一種技術更適合自己的需要之前，都必須考慮到兩者之間的權衡。本文在第2部分介紹了hypervisor和基於容器的虛擬化，在第3部分介紹了它的優缺點，並在第4部分深入介紹了基於容器的虛擬化及其背後的技術。已經有很多文獻對基於管理程序的虛擬化,而基於容器的虛擬化開始流行在過去的幾年裏和報紙關於這個話題越來越少,所以本文的重點是基於容器的虛擬化。本文的另一個重點是Docker，在4.3節中介紹了Docker，因爲Docker在過去的兩年中發展迅速，受到了社會的廣泛關注。爲了使本文更加完整，第5部分詳細介紹了基於容器的虛擬化和Docker的一般安全風險以及處理這些風險的可能方法。第6節簡要概述了與本主題相關的工作。

2 DISTINCTION: HYPERVISOR VS. CONTAINER-BASED VIRTUALIZATION

在談到虛擬化時，大多數人提到的技術是基於管理程序的虛擬化。hypervisor是一種允許從硬件進行抽象的軟件。系統管理程序必須模擬運行軟件所需的所有硬件。因爲有一臺計算機的完整硬件的仿真，所以談論虛擬機或虛擬計算機是很常見的。通常能夠通過hypervisor提供的接口訪問實際硬件，例如訪問CD或閃存等物理設備上的文件或與網絡通信。在這臺虛擬計算機中，可以像在任何普通計算機上一樣安裝和使用操作系統和軟件。運行hypervisor的硬件稱爲主機(操作系統稱爲主機操作系統)，而在它們內部運行的所有模擬機器都稱爲來賓操作系統，它們的操作系統稱爲來賓操作系統。現在，通常還會將實用軟件與管理程序結合在一起，以便方便地訪問管理程序的所有功能。這提高了操作的易用性，並可能帶來不屬於系統管理程序工作的其他功能，例如快照功能和圖形界面。可以區分兩種類型的管理程序，類型1和類型2管理程序。類型1的虛擬機監控程序直接運行在硬件上(因此通常稱爲裸機監控程序)，不需要操作系統，並且有自己的驅動程序，而類型2的虛擬機監控程序需要主機操作系統，主機操作系統的功能用於執行它們的操作。著名的管理程序或虛擬化產品有:

• KVM[2]:一個用於Linux內核的內核模塊，允許訪問真實硬件的虛擬化功能和模擬器，通常與KVM，qemu[3]一起使用，它正在仿真其餘的硬件(類型2)，
• Xen[4]:一個直接運行在硬件上的自由虛擬機監控程序(類型1)，
• Hyper-V[5]:從微軟集成到各種Windows版本的管理程序(類型1)，
• VMware工作站[6]:VMware專有虛擬化軟件(類型 2)
• Virtual Box[7]:來自Oracle的免費、獨立於平臺的虛擬化解決方案(類型 2)。
  從現在開始，在討論管理程序時，本文假設討論類型2管理程序。基於容器的虛擬化並不模擬整個計算機。操作系統爲容器軟件提供某些特性，以便將進程與其他進程和容器隔離開來。因爲Linux內核提供了許多隔離進程的功能，所以本文所討論的所有解決方案都需要它。其他操作系統可能提供類似的機制，例如FreeBSD的監獄[8]或Solaris區域。因爲沒有完全的硬件仿真，所以在容器中運行的軟件必須與主機系統的內核和CPU架構兼容。對於基於容器的虛擬化來說，一個非常有描述性的描述是“容器就像進程之間的防火牆”。基於虛擬機監控程序的虛擬化的類似比喻是運行在不同機器上的進程，這些機器連接到一箇中央實例hypervisor並由它進行監控。

3 USE CASES AND GOALS OF BOTH VIRTUALIZATION TECHNOLOGIES

Hypervisor和基於容器的虛擬化技術具有不同的權衡，因此每個技術都有不同的目標要實現。虛擬化通常也有不同的用例，因此虛擬機監控程序和基於容器的虛擬化都有與特定用例相關的特殊優勢和弱點。由於從硬件中抽象出來，這兩種虛擬化都很容易遷移，並且可以更好地利用資源，從而降低成本和節約能源

3.1 Hypervisor-based virtualization

基於管理程序的虛擬化允許完全模擬另一臺計算機，因此可以模擬其他類型的設備(例如智能手機)、其他CPU架構或其他操作系統。這在爲移動平臺開發應用程序時很有用——開發人員可以在開發系統上測試他的應用程序，而不需要訪問目標設備。另一個常見的用例是虛擬機與主機之外的其他客戶操作系統。有些用戶需要特殊的軟件，但這些軟件不能在他們喜歡的操作系統上運行，虛擬化允許在這個環境中獨立於主機系統運行幾乎所有需要的環境和軟件。由於來自硬件的抽象，所以更容易創建、部署和維護系統映像。在發生硬件事故的情況下，只需很少的努力就可以將虛擬機轉移到另一個系統，在最好的情況下，即使用戶沒有注意到有遷移。基於管理程序的虛擬化利用了現代CPU功能。這允許虛擬機及其應用程序以非特權模式[10]直接訪問CPU，從而在不犧牲主機系統安全性的情況下提高性能。
管理程序可以直接在硬件上設置(類型1)，也可以在主機操作系統上設置(類型2)。假設有一個類型 1 Hypervisor，那麼圖1中的所有操作系統都是來賓操作系統，而type 2 Hypervisor與其他用戶空間應用程序處於相同的級別，操作系統(圖中沒有顯示)和真正的硬件位於它下面的層上。

3.2 Container-based virtualization

基於容器的虛擬化利用內核特性爲進程創建一個隔離的環境。與基於管理程序的虛擬化不同，容器不會獲得自己的虛擬化硬件，而是使用主機系統的硬件。因此，在容器中運行的軟件可以直接與主機內核通信，並且必須能夠在操作系統上運行(參見圖2)，以及主機所運行的CPU架構。無需仿真硬件和引導完整的操作系統，容器就可以在幾毫秒內啓動，而且比傳統的虛擬機更高效。容器映像通常比虛擬機映像小，因爲容器映像不需要包含完整的工具鏈來運行操作系統，即設備驅動程序、內核或init系統。這就是爲什麼基於容器的虛擬化在過去幾年變得越來越流行的原因之一。較小的資源指紋允許在較小和較大的範圍內獲得更好的性能，並且仍然具有相對強大的安全性優勢。
在軟件開發中，封裝容器是一種非常有趣的方法:開發人員不需要手工設置他們的機器，取而代之的是，構建系統映像可能是分佈式的，其中包含處理項目所需的所有工具和配置。如果需要更新，則只需重新生成和分發一個映像。這種方法簡化了開發人員機器上不同項目的管理，因爲可以避免依賴衝突，並以一種簡單的方式分隔不同的項目。

4 FROM CHROOT OVER CONTAINERS TO DOCKER

基於容器的虛擬化使用內核提供的大量功能來隔離進程或實現其他有助於實現這一目的的目標。大多數解決方案都建立在Linux內核之上，由於本文的重點在於LXC和Docker，因此我們將仔細研究Linux內核提供的用於在容器中虛擬化應用程序的特性。因爲內核提供了所需的大部分功能，所以容器工具包通常不需要再次實現它們，並且內核代碼已經被其他軟件使用，這些軟件被認爲是穩定的，並且已經在生產中使用了。如果內核提供的機制存在安全問題，則會隨內核更新一起分發補丁，這意味着容器軟件不需要打補丁，用戶只需保持內核最新即可。

4.1 chroot

change root機制允許更改進程及其所有子進程的根目錄。Chroot用於限制文件系統對單個文件夾的訪問，目標進程及其子進程將該文件夾視爲根文件夾(/)。在Linux上，這不是一個安全特性，因爲用戶可以轉義chroot [11]。
除此之外，chroot還可以防止軟件錯誤訪問chroot之外的文件，而且—即使可以轉義chroot—也會使攻擊者更難訪問完整的文件系統。Chroot通常用於在某種隔離的環境中測試軟件並安裝或修復系統。這意味着除了將進程的根目錄更改爲文件系統中某個位置的另一個目錄外，chroot不提供任何進一步的進程隔離。
與正常的進程執行相比，將它們放到chroot中是一個相當弱的保證它不能訪問它們不應該訪問的文件系統的位置。

4.2 Linux containers

Linux containers [12] (LXC)是一個旨在構建一個將進程與其他進程隔離的工具包的項目。說,chroot並不發達的安全特性,可以逃避chroot——LXC試圖創建環境(容器),應該是防泄漏的過程及其子進程和保護系統即使攻擊者能夠逃脫容器。除此之外，它還提供了一個用於細粒度限制容器資源消耗的接口。容器完全虛擬化了網絡接口，並確保只能以安全的方式訪問內核接口。下面的小節將更詳細地介紹最重要的隔離機制。Linux容器(LXC)這個名稱可能有點讓人困惑:它是一個在Linux上創建容器的工具包，當然，除了LXC之外，還有其他方法可以實現與其他實用程序相同的目標，並在Linux下創建獨立的進程或它們的組(容器)。因爲LXC是一個受歡迎的工具包,本文的大多數語句指Linux容器適用於LXC,但是我們將使用術語LXC爲了專門談論流行的實現和Linux容器爲了談論的一般概念處理隔離在Linux上如本文所述。下面介紹的功能很難使用，這意味着正確的配置需要大量的閱讀文檔和大量的時間來設置一切。部署系統級工具的複雜配置是一項艱鉅的任務。在不危及現有解決方案安全性的情況下，將配置輕鬆地採用到其他環境和不同的需求幾乎是不可能的，因爲工具箱提供了對這些特性的訪問。LXC是一個試圖滿足這些需求的工具包。

4.2.1 Linux kernel namespaces

到目前爲止，進程只是chrooted的，但仍然可以看到其他進程，並且能夠看到用戶和組id等信息，訪問主機名並與其他進程通信。流程的目標是創造一個環境,讓他進入一個特殊的複製這些信息,不需要其他進程看到是一樣的,但是簡單的方法防止進程訪問這些信息可能會崩潰或導致錯誤的行爲。爲了實現這些需求，內核提供了一個稱爲namespaces 的特性(實際上，有幾個不同的[13]namespaces)。內核名稱空間是一個功能，它允許隔離進程、進程組甚至完整的子系統，如內核的進程間通信或網絡子系統。它是一種靈活的機制，通過爲需要分隔的進程創建不同的namespaces來分隔進程。內核允許將諸如網絡設備或進程/用戶/組id之類的全局資源傳遞到namespaces中，並管理這些資源的同步。可以創建包含進程ID (PID)的名稱空間，該進程ID已經在主機系統或其他容器中使用。這簡化了掛起容器的遷移，因爲容器的pid獨立於主機系統的pid。用戶名稱空間允許“隔離與安全相關的標識符和屬性，特別是用戶id和組id[…，root目錄，keys …和能力”[14]。將所有這些特性組合在一起，就有可能以這樣的方式隔離進程：

• 名稱空間中的進程id與其他名稱空間中的進程id是隔離的，並且每個名稱空間都是唯一的，但是不同名稱空間中的進程可能具有相同的進程id，
• 如果需要，可以通過內核提供的API訪問全局資源，
• 主機系統和容器的用戶、組和其他安全相關信息的抽象。
  實際上，kernel namespaces是進程分離的基礎，因此也是實現基於容器的虛擬化的關鍵概念之一。它們提供了構建容器所需的許多特性，從2.6.26內核開始就可用，這意味着它們已經存在了好幾年，並且已經在生產環境中使用了。

4.2.2 Control groups

爲了將進程與其他進程隔離，控制組(進一步稱爲cgroups)是一個非強制性的特性。首先，cgroups是一種跟蹤進程和進程組(包括分叉進程)的機制。[16]在第一種情況下,他們不解決問題與處理隔離或隔離更強,但鉤子允許其他子系統提供擴展這些功能和實現細粒度的資源控制和限制其他工具相比更靈活試圖實現類似的目標。將資源分配給流程和流程組並管理這些分配的能力允許計劃和控制容器的使用，而不會無限制地浪費簡單容器的物理資源。同樣，可以保證資源不是不可用的，因爲其他進程正在爲自己聲明資源。乍一看，這可能是一個主要針對服務於多個不同用戶的主機的功能(例如共享網絡主機)，但它也是一個避免拒絕服務(DoS)攻擊的強大機制。DoS攻擊不會危害系統，它們試圖生成無用的工作負載，通過過度的壓力阻止服務完成其任務。一個行爲與被懷疑的容器不同的容器可能會有一個未知的bug，可能會被攻擊者攻擊甚至控制，並且會消耗大量的物理資源——從一開始就限制對這些資源的訪問可以避免中斷，並且可能會節省所有相關人員的時間、金錢和精力。如前所述，控制資源不是隔離所必需的特性，而是與基於管理程序的虛擬化競爭所必需的特性。在基於管理程序的虛擬化中，限制資源使用是很常見的，而能夠對容器做同樣的事情可以更好地利用給定的資源。

4.2.3 Mandatory Access Control

對這類系統的需求通常是爲了提高安全性，在這種情況下，MAC用於加強Linux/Unix的訪問控制機制。相反，如果請求資源，則檢查授權規則(策略)，如果滿足策略定義的需求，則授予訪問權。如何實現這樣一個系統有不同的方法，主要有三種:SELinux[17]、AppArmor[18]和grsecurity的RBAC[19]。MAC策略通常用於限制對敏感資源的訪問，這些敏感資源在特定上下文中不需要訪問。例如，Linux上的chsh1 namespace功能程序設置了setuid位。這意味着一個普通用戶可以運行這個二進制文件，而這個二進制文件可以將其自身提升爲使用root特權運行，從而完成所需的工作。如果在二進制文件中發現了一個bug，就可能以普通用戶的身份使用root權限執行惡意代碼。可以提供一個MAC策略，允許二進制文件提升其權限，以完成其合法的工作，但拒絕root可以做但庫不需要做的所有事情。
在本例中，chsh二進制文件沒有用於聯網的用例，但是允許這樣做，因爲它可以執行root可以執行的任何操作。政策拒絕訪問網絡相關的系統組件不影響二進制但是如果它被攻擊者利用,他無法用二進制來嗅嗅活躍的網絡接口或更改默認網關流量捕獲數據包,因爲自己的盒子一個MAC政策是否認chsh工具訪問網絡子系統。有很多例子bug在軟件讓攻擊者訪問敏感信息或惡意的活動不需要的攻擊過程,例如cve - 2007 - 33042這是一個錯誤的Apache web服務器允許攻擊者發送信號到其他進程在執行模式被啓用SELinux減輕已經[10]。特別是網絡服務，如web或郵件服務器，以及連接的系統，如數據庫服務器，正在接收不可信的數據，是潛在的攻擊目標。將它們對資源的訪問限制在最小需求範圍內可以提高系統和所有連接系統的安全性。將這些安全改進應用於容器增加了另一層保護，以減少來自容器內部的對主機和其他容器的攻擊。

4.3 Docker

LXC是一個處理容器的工具包，使用戶不必使用低層機制。它創建了一個接口來訪問Linux內核提供的所有特性，同時減少了用戶的學習曲線。如果沒有LXC，用戶需要花費大量時間閱讀內核文檔，以便理解和使用提供的特性手動設置容器。LXC允許自動化容器管理，並允許用戶構建自己的容器解決方案，該解決方案可定製，甚至可以滿足特殊需求。對於那些只想在一個隔離的環境中簡單地運行進程而不想花太多時間弄清楚工具包是如何工作的人來說，這仍然是不切實際的。這就是Docker[1]的作用:它是一個命令行工具，允許創建、管理和部署容器。與使用LXC完成相同的任務相比，它只需要很少的技術背景，並且提供了在生產環境中使用容器所必需的各種特性。Docker於2013年3月啓動，受到廣泛關注，項目發展迅速。通過將隔離進程的技術與其他有用工具相結合，Docker使得基於其他容器映像創建容器映像變得更加容易。它允許用戶訪問internet上一個名爲Docker Hub[20]的公共存儲庫，該存儲庫包含數百個可用的鏡像，可以通過一個命令下載並啓動它們。用戶有能力改變和擴展這些圖像，並與他人分享他們的改進。還有一個API允許用戶與Docker進行遠程交互。與LXC的使用相比，Docker帶來了很多改進，但也在一個不再那麼技術性的層上引入了新的攻擊向量，因爲現在用戶及其行爲在整個系統的安全性中發揮了更大的作用。在更詳細地討論它之前，我們先概述一下LXC Docker的一些主要改進。

4.3.1 One tool to rule them all

LXC是一個強大的工具，支持廣泛的設置，因此，如果不深入研究主題和工具，就很難獲得它。Docker旨在簡化工作流程。Docker命令行工具是用戶與Docker守護進程交互的接口。它是一個具有可記憶的參數名稱的命令，允許用戶訪問所有特性。根據環境的不同，從在線存儲庫(Docker Hub)提取(下載)圖像並在系統上運行所需的配置很少，甚至不需要配置。除了不是必需的之外，當然還可以爲Docker和特定的鏡像創建配置文件，以便簡化管理、設置特定的參數和自動化新映像的構建過程。

4.3.2 Filesystem layers generated and distributed independently

與經典的 hypervisor-based virtualization程序的相比，虛擬化Docker一個主要的改進是文件系統層的使用。文件系統層可以看作是文件系統的不同部分，即容器的root文件系統和包含應用程序特定文件的文件系統。可能有不同的文件系統層，例如一個基本的系統可能總是需要的和額外的層包含文件，例如一個網絡服務器。這意味着可以將準備運行的web服務器作爲獨立的文件系統層分發。通過例證的方式組成的web服務是一個SQL數據庫服務器像MySQL、Apache這樣的網絡服務器,一個編程語言和框架的web應用程序是建立在python使用Django和一個郵件傳輸代理像sendmail。當然，在一定程度上可以拆分這些工具並在不同的環境中運行它們(郵件、web和數據庫可能在完全不同的機器上運行)，本例假設設置是開發人員設置，與生產使用中的部署不同。在安裝Docker後,可以獲取文件系統層的所有這些工具,並將其組合在一起,一個圖像,上面提到的所有軟件,現在可能爲了開發web應用程序使用。現在的web應用程序本身可能是一個新的文件系統層的內容允許部署以後以同樣的方式。如果發佈了其中一個組件的新版本，而開發人員希望更新其本地層，則只需要獲取更新後的層。用戶的配置通常保持在一個單獨的層中，不受更新的影響。因爲不需要再次獲取其他層的數據，所以節省了空間和帶寬。如果另一個用戶想要使用web應用程序開發人員推到碼頭工人中心,但他更喜歡PostgreSQL / MySQL和nginx / Apache web服務器和web應用程序可以使用這些替代的開發人員的設置中,他可能會使用各自的他想要使用的文件系統層軟件。

4.3.3 Docker Hub

如前所述，Docker Hub[20]是引入虛擬化市場的新技術之一。這是沒有人需要的東西，因爲它根本不存在，每個人都很好地從頭開始閱讀文檔，創建虛擬機和容器映像。Docker Hub是一個完全集成到Docker軟件中的web服務，允許從Docker Hub獲取準備運行的圖像。用戶創建或修改的圖像也可以在Docker Hub上共享。結果是,Docker hub包含了很多不同的軟件的圖像在不同的配置和每個用戶有能力獲取圖像和文檔的圖像,使用和提高並與其他用戶聯繫評論圖片和合作。Docker Hub也可以通過web瀏覽器訪問。爲了方便選擇正確的圖像經常使用的圖像，如Wordpress, MongoDB和Node。Docker Hub允許這些項目將它們的圖像標記爲直接來自已聲明的項目成員的官方圖像。每個人都可以將自己的映像推送到Docker Hub，這帶來了極大的多樣性和大量可用的容器映像軟件。甚至可以在那裏找到一些更復雜或更具體的程序配置。Hub還引入了第5節中介紹的一些安全問題。用戶不綁定到Docker Hub。可以設置私有註冊中心，以同樣的方式在本地使用，但是例如，只有在公司網絡中通過身份驗證的用戶才能訪問，或者爲了構建獨立於現有結構的公共結構。

4.4 Managing great numbers of containers

運行容器在資源消耗方面很便宜。依賴於容器結構構建大型服務可能涉及位於世界各地不同機器上的數千個容器。今天，這可能仍然是一個特例，但一些公司已經面臨管理問題，因爲他們有太多的容器，無法手工管理。谷歌引入了Kubernetes[21]，以便簡化管理，對容器進行分組，並自動處理容器組。

5. SECURITY OF CONTAINER-BASED VS. HYPERVISOR-BASED VIRTUALIZATION

基於管理程序的虛擬機通常用於通過將暴露給攻擊者的資源與需要保護的其他資源隔離來引入另一層安全。正確配置的容器有一個安全配置文件，它比一個服務器上的多個應用程序稍微安全一些，比KVM虛擬機稍微安全一些。與相鄰的多個應用程序相比，[10]具有更好的安全性，這是因爲前面提到的機制使得從隔離的環境中逃逸變得更加困難，但是所有容器中的所有進程仍然與主機內核下的其他進程一起運行。由於KVM是一個虛擬機監控程序，它模擬完整的硬件和內部的另一個操作系統，因此很難逃離這個環境，因此基於虛擬機監控程序的虛擬化的安全性稍微高一些。
可以將這兩種技術結合在一起，由於資源少，而且引入了基於容器的虛擬化的安全層，這被認爲是一個好主意。儘管如此，基於容器的虛擬化並沒有被證明是安全的，容器突破在過去的[22]中已經發生了。
共享圖像的精神產生了多種安全問題。Docker已經很長一段時間沒有足夠的機制來檢查下載的圖像的完整性和真實性,這意味着圖像的作者確實是形象的人聲稱他們是誰,沒有被修改而不被認可,相反他們的系統暴露的攻擊表面,它可能被攻擊者可以修改圖像和經過Docker的驗證機制[23]。Docker通過集成一個名爲Content Trust的新機制解決了這個問題，該機制允許用戶驗證圖像的發佈者[24]。對於基於管理程序的虛擬化軟件來說，Docker Hub是無與倫比的，這意味着通常從頭開始構建虛擬機。在Linux中，一方面包被簽名並且真實性和完整性可以被驗證是很常見的，另一方面每個虛擬機都包含大量的軟件，這些軟件需要手工處理。
Docker最大的問題之一是很難處理大量包含安全漏洞的圖像。這個問題的起因是Docker Hub上的圖像不會自動更新，每次更新都需要手工構建。這是一個相當社會的問題，人們不更新他們的軟件，也不更新他們過去推送到Docker Hub的容器。與虛擬機上軟件不更新的現象相比，這是一個比較困難的問題:Docker Hub實際上沒有可用的更新，最新的映像包含漏洞。在虛擬機上，當運行仍然需要維護的操作系統時，需要有人登錄並安裝安全更新，由於各種原因，這些更新可能會被遺忘或簡單地忽略，但是作爲用戶構建固定的容器通常需要更多的工作。
一項研究發現[25]，“Docker Hub中超過30%的官方圖片存在高優先級的安全漏洞”。這些數字是由掃描Docker Hub上列出的圖像以查找已知漏洞的工具生成的。超過60%的官方圖像(這意味着它們來自容器中包含的項目的官方開發人員)包含中等或高優先級的漏洞。對中心上所有圖像的漏洞進行分析，發現75%的漏洞都是考慮中、高優先級的問題。克服這些問題需要對容器進行永久性的分析，這意味着定期掃描容器以發現安全問題，並將發現的問題通知容器的創建者和用戶。這意味着可能更容易出現過時容器的問題，因爲它們集中存儲的事實允許靜態掃描存儲庫中的所有圖像。
海登指出，如何從頭構建一個安全的LXC容器，它可以用作進一步修改[10]的基礎。

6. RELATED WORK

虛擬機監控程序和基於容器的虛擬化的一個用例是通過隔離不受信任的進程或連接到其他系統的進程來提高安全性，並暴露攻擊面，即連接到internet的機器上的web服務器。當然，還有其他方法可以提高虛擬化的安全性。
另一種分離應用程序的方法可以在Qubes OS[26]項目中找到。他們建立一個基於Linux的操作系統和X11窗口系統的XEN,允許創建AppVMs專用的虛擬機中運行的應用程序——在某種程度上類似於容器的方法,但由於基於管理程序的虛擬化,而不是建在一個標準的Linux內核機制。根據他們的主頁，甚至可以運行基於Microsoft Windows的應用程序虛擬機。
MirageOS[27]也是在XEN上設置的操作系統，但是在MirageOS上部署應用程序意味着部署包含應用程序的專門內核。這些unikernel[28]只包含執行其唯一任務所需的內容。因爲沒有不是絕對必需的特性，所以通常情況下，unikerkernel非常小，而且性能非常好。MirageOS是一個庫操作系統，可以用來創建這樣的unikerkernel。這種方法可能最大的缺點是，應用程序需要專門編寫來與unikerkernel一起使用。

7. CONCLUSION

對於那些不需要或不希望擁有獨立的模擬硬件和操作系統內核(系統中的系統)的人來說，基於容器的虛擬化是基於管理程序的虛擬化的輕量級替代方案。在許多場景中，速度、簡單性和只需要隔離進程是普遍存在的，而基於容器的虛擬化滿足了這些需求。通過使用Linux內核中已經存在多年的大部分特性，基於容器的虛擬化構建在一個成熟的代碼庫之上，這個代碼庫已經在用戶的機器上運行，並且由Linux社區保持最新。特別是Docker引入了一些與虛擬化無關的新概念。爲用戶提供協作、共享和重用其他用戶的工作的社交方面無疑是Dockers成功的祕訣之一，也是虛擬化領域的一個全新理念。因爲運行大量容器相對容易，所以已經有工具可以管理大量的容器。
當涉及到安全問題時，不需要“vs”。在這篇論文的標題中。通常，當然可以在已經虛擬化的計算機上運行容器，或者在容器中運行管理程序。hypervisor 層被認爲是比上面描述的機制的應用程序更厚的安全層。然而，應用這些輕量級機制增加了額外的安全性，而且幾乎不需要任何資源。