云计算

作者|王旭蚁金服资深技术专家

本文从《CNCF x Alibaba 云原生技术公开课》第28集开始整理，

单击直达课程页面。

关注“阿里巴巴云原生”公众号并回复关键词

在“入门”中，可以下载从零开始的入门K8s系列文章PPT。

一.吉利：安全容器命名

Phil Karlton有一句名言：“计算机科学界只有两个真正的难题——缓存被命名为禁用。”

我相信对我们的容器圈来说，“命名”绝对配得上这个词。 毫无疑问，这将使老开发者保持沉默，让新人落泪。 单就系统软件而言，我们今天比较通行

“Linux容器技术”的概念曾经使用过Jail、Zone、Virtual Server、Sandbox等名称。 同样，早期的虚拟化技术堆栈将虚拟机类型称为容器。 也就是说，这个词本身是指用于包含、封装和隔离的器物。 过于常见，以严谨著称的维基百科有“OS-Level Virtualization”(系统级虚拟化)这样的词条，避免了“什么是容器”的问题。

2013年，docker问世后，集装箱的概念伴随着不变的基础设施、云原生的一系列概念，在接下来的几年中以枯萎腐朽之势迫切需要引入基于“封装配置”细粒度组合的APP应用，简单如何引入APP，在这里好像有点离题，但我想在这里强调的是：

“云环境下的容器实际上以标准格式封装有“APP应用容器”——，在标准操作系统环境(常常为Linux ABI )下运行的APP应用程序可以封装——，也可以封装该应用程序”

这个定义是我下的，但那不是我的个人意愿，而是根据OCI规范这个共识写的。 该规范规定了容器中的APP应用程序所处的环境和行为方式。 例如，哪些可执行文件将在容器的根文件系统中运行、由哪些用户运行、需要哪些CPU、哪些内存资源、外部存储以及共享要求。

因此，标准格式的软件包、标准的操作系统环境一起以APP应用为中心构成了APP应用容器的软件包。

基于这个共识，我们可以谈论安全容器。 当时，我和我的共同创始人赵鹏用“虚拟化容器”这个名字命名了我们的技术。 但是，为了吸引眼球，使用了“Secure as VM，Fast as Container”这样的Slogan。 于是，在集装箱安全问题上击中中心的人们马上使用了“安全容器”和“安全容器”。在我们心目中，这是一种额外的隔离，它是安全的一环，但用户可以选择安全容器和安全容器的定义如下

安全容器是一种运行时技术，它为容器APP提供完整的操作系统运行时环境(通常为Linux ABI )，通过将APP应用程序的运行与宿主机操作系统隔离，防止APP应用程序直接访问主机资源

这是我们的安全容器。

二、间接层：安全容器精髓

安全容器时，使用“间接层”一词。 这是Linus Torvalds在2015年的LinuxCon上提出的：

“安全问题的唯一正确答案是允许出现这些(导致安全问题的)错误，但通过附加的隔离层阻止它们。 ”

为了安全起见，为什么要引入隔离层呢？ 其实像Linux本身这样的规模非常大，理论上无法验证程序中没有错误。 因此，如果利用了正确的错误，安全风险就会成为安全问题。 的框架和修补程序无法确保安全性，因此需要进行额外的隔离，以降低漏洞及其导致的被完全打破的风险。

这就是安全容器的由来。

三. Kata Containers :云原生物化学虚拟化

2017年12月，我们在KubeCon上对外宣布了Kata Containers的安全容器项目。 这个项目有两个前身。 这是我们以前发起的runV和Intel clear container项目。 这两个项目都是2015年5月开始的，实际上比Linus在KubeCon 2015上说的话还要早。

那些想法很简单：

操作系统本身的容器机制无法解决安全问题，需要隔离层

虚拟机本身、虚拟机、它是现成的隔离层，如AlibabaCloud (阿里巴巴云)、AWS等，它们都使用了虚拟化技术，因此对全球用户来说，“安全虚拟机”

如果中包含内核，则可以支持前面提到的OCI定义。 这意味着提供了一个Linux ABI运行时环境，在此运行时运行Linux ABI并不是很难。

目前的问题是虚机不够快，妨碍了其在集装箱环境中的应用。 如果能拥有“speed of container”，我们也许就能拥有使用虚拟机进行隔离的安全容器技术。 这也就是Kata Containers自己的想法之一，就是用虚拟机制作Kubernetes的PodSandbox。 Kata中作为VM使用的有qemu、firecracker、ACRN、cloud-hypervisor等。

下图显示了Kata Containers如何与Kubernetes集成。 这里的例子使用了containerd。 当然CRI-O也一样。

目前，Kata Containers通常用于Kubernetes。 首先，Kubelet通过CRI接口找到容器或CRI-O。 此时，例如镜像这样的操作通常也由containerd或CRI-O执行。 根据需要，将运行时部分的需求转换为OCI spec，并交给OCI运行时执行。 例如，上半部分的kata-runtime或下半部分的containerd-shim-kata-v2被简化。 具体流程如下。

当containerd收到请求时，首先创建shim-v2。 该shim-v2是PodSandbox的代表，即该VMM的代表；

每个Pod都有一个shim-v2，用于执行containerd/CRI-O的各种操作。 shim-v2为此Pod启动了一个虚拟机，其中正在运行linux kernel，即图中的Guest kernel。 如果它使用qemu，则使用一些配置和一些修补程序，使其变小。 同时这也没有多余的Guest，完整的CentOS、Ubuntu这样的操作系统不会跑；

然后，将此容器的spec和此容器自身的打包存储(包括rootfs和文件系统)传递给此PodSandbox。 该PodSandbox是kata-agent在虚机中启动容器；

根据CRI语义和OCI规范，可以在一个Pod内启动多个相关容器。 它们位于同一虚拟机上，并可以根据需要共享部分namespace。

除此之外，其他外部存储器和卷也可以通过热插拔插入此PodSandbox

对于internet，现在使用tcfilter可以无缝访问几乎所有Kubernetes的CNI插件。 它还提供了enlightened的模型。 这样，就有了特殊的CNI插件来提高容器的网络能力。

可以看到，在我们的PodSandbox中，实际上只有一个Guest Kernel在运行容器本身的打包和容器APP，并不包含完整的操作系统。 也就是说，与传统的虚拟机不同，该过程通过共享可共享的内存而不需要容器引擎，来进一步降低容器的内存开销。

与传统的虚拟机相比，开销少，启动轻便，几乎所有场景都可以实现“secure as VM”、“fast as container”。 此外，除了安全技术之外，它比传统虚拟机更灵活，并且在物理上对计算机的操作体验更少，包括动态资源插拔和使用virtio-fs的技术。 这是一种这样的技术，它将为我们这样的场景、为kata这样的场景创建的host的基本文件系统的内容，例如容器的rootfs共享给虚拟机。

根据以前为非易失性存储器、非易失性存储器制作的DAX技术，可以在不同PodSandbox之间，即不同Pod之间、不同容器之间共享的只读存储器部分。 这样可以在不同的PodSandbox之间大幅节约内存。 同时，所有Pod的管理都是通过Kubernetes从外部进行集装箱管理，从外部获取metrics和debug信息，没有登录虚拟机的触感。 因此，虽然看起来像是非常容器化的操作，但从基础上看是虚拟机，但实际上是针对云本机的虚拟化。

四. gVisor :流程级虚拟化

gVisor，这称为过程级虚拟化。 这是和kata不同的方法。

2018年5月，在哥本哈根的KubeCon上，谷歌表示为了应对kata containers，将开源开发5年的gVisor安全容器，并有不同的安全容器解决方案

如果说Kata Containers通过对现有隔离技术的组合改造构建了容器间的隔离层，那么gVisor的设计显然更加简洁。

如上图右侧所示，这是一个以Go语言重写的在用户状态下运行的操作系统内核，该内核名为sentry，与虚拟化和虚拟机技术无关。 而是利用内部称为Platform (平台)的功能，让主机操作系统执行操作，并将APP应用程序期望的所有操作系统操作交给sentry

gVisor是一个纯粹面向APP应用的隔离层，从一开始就不完全等同于虚拟机。 那是为了在Linux上运行Linux程序。 作为隔离层的安全性依据如下

gVisor的开发者必须首先减小攻击面，宿主机的操作系统只需为沙箱中的APP应用提供约20% %u7684系统调用

Linux大约有300多个Syscall。 实际上，sentry最后一次向操作系统发出的呼叫集中在60多个Syscall上。 这源于gVisor的开发者们对操作系统的安全性进行了一些研究，发现对操作系统的成功攻击大多来自不常见的系统调用。

这个很容易理解。 由于不常用的系统调用，其实现路径一般为旧路径。 也就是说，这些部分的开发一般不太积极，很少开发人员进行维护。 受欢迎路径的代码更安全，因为它被review的次数很多。 因此，gVisor的设计无法达到操作系统级别的APP应用程序对不常用的Syscall的访问，只能通过sentry进行处理。

从sentry访问宿主机时，如果只使用经过验证的、比较成熟的、比较热的路径上的系统调用，安全性会比原来更高。 我们现在Syscall是1/5，但被攻击的可能性不到1/5。

然后，我发现一些经常被攻击的系统调用需要隔离，如open ( )。 打开文件的操作

在Unix系统上，因为大多数东西都是一些文件，所以open变得可以做太多，大多数攻击都是通过open进行的。 gVisor的开发者单独将open放入一个被称为Gofer的独立过程中实现。 独立的过程实际上有更多的容器受到seccomp、一些系统限制和一些“capbility drop”的保护。 优惠可以更少，可以在root之外运行，从而进一步提高系统的整体安全性。

最后，sentry和Gofer都是用Go语言实现的，不是用传统的c语言实现的。

o语言本身是一种更安全的内存实现，因此整个gvisor更不容易受到攻击，也更不容易出现内存问题。 当然，Go语言在一些地方还不太系统。 gVisor的开发者也坦言，为了做到这一点，对Go Runtime进行了很多调整，并将它们反馈到了Go语言社区。

可以说gVisor的体系结构非常漂亮。 很多开发者对我很诚实。 他们其实很喜欢gVisor的架构，我觉得这个更简单、更纯粹、更干净。 当然，它的架构很漂亮，但是重新实现一个内核也只有谷歌这样的巨头才能做到。 同样，可能还有微软的WSL 1。 而且这个设计很先进，其实有几个问题：

首先，sentry不是Linux，所以在兼容性方面与kata这样的计划相比还有差距。 虽然这是没办法，但对于特定APP应用来说，这可能不是问题；

其次，对于现在的系统调用的安装方式，以及CPU的命令系统，从APP应用程序屏蔽Syscall，将该Syscall发送到sentry进行运行，这一过程本身有很多开销。 在某些场景下，gVisor可以具有更好的性能。 但是，在大多数场景中，gVisor的性能仍然比不上kata这样的解决方案。

因此，在短期内，像gVisor这样的解决方案不会成为终极解决方案，但会针对特定场景提供提示。 我觉得这个启示对未来操作系统、CPU指令集的发展可能会有点帮助。 而且，我相信将来无论是kata还是gVisor，都会有进化。 最后，我们希望有一个共同的解决方案来统一解决APP应用程序的执行问题。

五.安全容器：不仅仅是安全

安全容器的名称是安全的，但提供了隔离性。 它的作用不仅仅是安全。

实际上，这一附加隔离层带来的影响，因为安全容器通过隔离层APP ——的问题，无论是外部恶意攻击还是意外错误，都不会影响主机，也不会在不同的Pod之间相互影响这有助于保护系统调度、服务质量和APP应用信息。

传统的操作系统容器技术是内核进程管理的扩展，容器进程本身是一组相关的进程，对宿主机调度系统来说完全可视，一个Pod中的所有容器或进程同时宿主机这意味着，在具有大量容器的环境中，主机本身的内核负担很大，在许多实际环境中可以观察到该负担带来的开销。

特别是现在，随着计算机技术的发展，可以看到一个OS有大量的内存，大量的CPU，几百g的内存。 在这种情况下，如果分配的容器数量很大，则会给调度系统带来非常大的开销。 采用安全容器后，主机将无法看到这些完整的信息。 由于该隔离层负责调度应用于隔离层之上，因此在主机上只需调度这些沙箱本身，从而减少了宿主机的调度开销。 因此，日程效率会提高。

在提高调度效率的同时，隔离所有APP应用程序。 这样可以避免容器之间、容器和主机之间的干扰，提高服务质量。 从另一个方向看，制作安全容器的初衷是保护宿主机免受容器内恶意和有问题的APP应用的影响，相反，作为云可能会面临恶意攻击，因此也是保护自己。

另外，用户不想访问用户的资源太多。 用户需要使用资源，但不需要查看数据。 安全容器可以将用户正在运行的内容完全封装在容器中。 这样可以防止主机运维管理操作访问APP应用程序中的数据，并在不接触用户数据的情况下保护APP应用程序中的数据。 我们要想以云的形式访问用户数据，必须给予用户许可。 此时，用户不知道你是否在进行什么恶意的操作。 如果我们的沙箱封装得很好，就不需要征求用户的许可。 这对于保护用户的隐私来说是更好的。

展望未来，我们将会看到，不仅安全容器是安全隔离的，安全容器隔离层的内核相对于宿主机的内核是独立的，而且是专用于APP服务的。 从这个角度看，主机和APP功能之间实际上已经进行了合理的功能分配和优化。 这可以展示很多潜力，未来的安全容器不仅可以降低隔离性能的开销，还可以提高APP应用的性能。 隔离技术使云原生基础设施更加完善。

六.正文总结

正文的主要内容到此为止，现简单总结如下：

目前，“安全容器”是一种容器运行时技术，它为容器APP提供完整的操作系统运行时环境(通常为Linux ABI )，但将APP应用程序与宿主机操作系统隔离，并且APP应用程序不直接访问主机资源

Kata Containers是一个使用虚拟化提供隔离层的开放源代码安全容器项目，与Kubernetes等云的本机生态系统完全兼容，托管在OpenStack Foundation中，ai

gVisor是利用流程级虚拟化技术实现的安全容器技术，由谷歌开发并开源，通过Go语言实现了用户状态的兼容内核。

最后，安全容器提供的隔离性不仅可以提供安全环节，还可以提供性能、调度、管理方面的隔离。

「

云原关注微服务、Serverless、容器、Service Mesh等技术领域，关注云原流行技术趋势、云原大规模落地实践，最好是云原开发者的公众号”

详情请访问云服务器、域名注册、虚拟主机的问题，请访问西部数码代理商官方网站： www.chenqinet.cn