论文阅读 Hypervisor- vs. Container-based Virtualization

Hypervisor- vs. Container-based Virtualization

• ABSTRACT
• 1 INTRODUCTION
• 2 DISTINCTION: HYPERVISOR VS. CONTAINER-BASED VIRTUALIZATION
• 3 USE CASES AND GOALS OF BOTH VIRTUALIZATION TECHNOLOGIES
• • 3.1 Hypervisor-based virtualization
  • 3.2 Container-based virtualization
• 4 FROM CHROOT OVER CONTAINERS TO DOCKER
• • 4.1 chroot
  • 4.2 Linux containers
  • • 4.2.1 Linux kernel namespaces
    • 4.2.2 Control groups
    • 4.2.3 Mandatory Access Control
    • 4.3 Docker
    • 4.3.1 One tool to rule them all
    • 4.3.2 Filesystem layers generated and distributed independently
    • 4.3.3 Docker Hub
    • 4.4 Managing great numbers of containers
• 5. SECURITY OF CONTAINER-BASED VS. HYPERVISOR-BASED VIRTUALIZATION
• 6. RELATED WORK
• 7. CONCLUSION

ABSTRACT

1 INTRODUCTION

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)

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与其他用户空间应用程序处于相同的级别，操作系统(图中没有显示)和真正的硬件位于它下面的层上。

4 FROM CHROOT OVER CONTAINERS TO DOCKER

4.1 chroot

机制允许更改进程及其所有子进程的根目录。Chroot用于限制文件系统对单个文件夹的访问，目标进程及其子进程将该文件夹视为根文件夹(/)。在Linux上，这不是一个安全特性，因为用户可以转义chroot [11]。
除此之外，chroot还可以防止软件错误访问chroot之外的文件，而且—即使可以转义chroot—也会使攻击者更难访问完整的文件系统。Chroot通常用于在某种隔离的环境中测试软件并安装或修复系统。这意味着除了将进程的根目录更改为文件系统中某个位置的另一个目录外，chroot不提供任何进一步的进程隔离。
与正常的进程执行相比，将它们放到chroot中是一个相当弱的保证它不能访问它们不应该访问的文件系统的位置。

4.2 Linux containers

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

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 层被认为是比上面描述的机制的应用程序更厚的安全层。然而，应用这些轻量级机制增加了额外的安全性，而且几乎不需要任何资源。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树容器(docker)docker container 操作8726 人正在系统学习中