安全容器技术

　　安全容器是一种运行时技术，为容器应用提供一个完整的操作系统执行环境（常常是 Linux ABI），但将应用的执行与宿主机操作系统隔离开，避免应用直接访问主机资源，从而可以在容器主机之间或容器之间提供额外的保护。

　　云原生语境下的容器，实质是「应用容器」——是以标准格式封装的，运行于标准操作系统环境（常常是 Linux ABI）上的应用打包——或运行这一应用打包的程序/技术。 --OCI

　　　　Linux ABI（Application Binary Interface）定义了应用程序与操作系统之间的二进制接口规范，确保二进制程序在不同的 Linux 系统上能够正确运行。ABI 包括一系列的规则，涵盖了函数调用约定、寄存器使用、数据结构布局等方面，以确保二进制程序与系统库之间的兼容性。

　　为什么要引入隔离层呢？其实 Linux 本身这样的规模是非常大的，无法从理论上来验证程序是没有 Bug 的，于是，一旦合适的 Bug 被利用，安全性风险就变成安全性问题了。安全性的框架和修补并不能确保安全，所以我们需要进行一些额外的隔离来减少漏洞以及因为这些漏洞造成的被彻底攻破的风险。

　　虚拟机，VM，它是一个现成的隔离层。虚拟机中如果有个内核，就可以支持 OCI 的定义，也就是说提供了 Linux ABI 的运行环境，在这个运行环境中跑一个 Linux 应用不太难实现。

　　 PodSandbox 里面，实际上只有一个 Guest Kernel 跑着一些容器本身的打包和容器应用，并不包含一个完整的操作系统。就是说，这个过程，它用起来并不像是传统的虚拟机，对于容器来说，它只有容器的引擎，并且通过少用不必要的内存、共享能共享的内存来进一步地降低内存的开销。

 

gVisor：进程级虚拟化

gVisor 是一个纯粹的面向应用的隔离层，它使用一个用 Go 语言重写的运行在用户态的操作系统内核，这个内核的名字叫做 sentry，它并不依赖于虚拟化和虚拟机技术，相反，它是借助一个它们内部叫做一个 Platform（平台）的能力，让宿主机的操作系统做一个操作，把应用所有的期望对操作系统的操作都转交给 sentry 来进行，sentry 做处理之后会把其中的一部分交给操作系统来帮它完成，大部分则由自己来完成。

　　宿主机的操作系统将只为沙箱里的应用提供大约 20% 的系统调用。

　　隔离出来一些经常被攻击的系统调用

问题：sentry 并不是 Linux，所以在兼容性方面与 kata 这样的方案比起来还是有一定的差距的

　　　对于当前的系统调用的实现方式，还有 CPU 的指令系统来说，我们从应用去拦截 Syscall，再把这个 Syscall 送给 sentry 去执行，这个过程本身是有相当大的开销的。在一定场景之下，gVisor 是可以有更好的性能的。但是，在大部分的场景之下，gVisor 的性能仍然是比不上 kata 这样的解决方案的。

安全容器：不止于安全

安全容器通过隔离层让应用的问题——不管是来自于外部的恶意攻击还是说意外的错误，都不至于影响主机，也不会在不同的 Pod 之间相互影响，所以实际上，这个额外的隔离层，它所带来的影响不只是安全，还有其它的方面。它对于系统的调度、服务质量，还有应用信息的保护都是有好处的。

传统的操作系统容器技术是内核进程管理的一个延伸，容器进程本身是一组相关联的进程，对于宿主机的调度系统来说，它是完全可见的，一个 Pod 里的所有容器或进程，同时也都被宿主机调度和管理。这就意味着，如果你有一个大量容器的环境，宿主机本身内核的负担就会很重，在很多实际环境中已经可以观察到这个负担带来的开销了。

如果分配的容器数量很多，调度系统就会有非常沉重的开销。在采纳安全容器之后，在宿主机上就看不到这些完整的信息了，这个隔离层同时承担了一些对隔离层上面应用的调度，于是在主机上面就只需要调度这些沙箱本身，降低了宿主机的调度开销，这也就是它为什么会提高调度效率的原因。

安全容器可以把用户运行的东西完全封装在容器里，这样的话可以让主机的运维管理操作并不能访问到应用的数据，从而把应用的数据保护在沙箱里，不需要去碰到用户数据。

安全容器不仅仅是在做安全隔离，安全容器隔离层的内核相对于宿主机的内核是独立的，专门对应用服务，从这个角度来说，主机和应用的功能之间实际上是一个合理的功能分配与优化。它可以展现出很多的潜力，未来的安全容器，可能不仅仅是隔离性能开销的降低，同时也是在提高应用的性能。隔离技术会让云原生基础设施更加完美。