基于Rust-vmm实现Kubernetes运行时，你值得拥有

• 利用一些Security Tools，包括经常用的SElinux或者Cgroup隔离，划分不同的资源访问和安全规则，但是这些安全规则需要编写大量的profile文件，实现起来难度颇大。

• 入侵检测机制，主机防御的一种手段。入侵检测的软件或者进程会监控这台主机上有风险的进程或者有风险的文件，对于这些文件的读写操作都会有安全方面的记录，会即时预警，即时响应。比如对于containerd-shim/busybox/docker-runc的关键进程，比如docker-runc对于bash、init或者对于fd的访问都可以做到即时的预警和标记。对于上面提到的容器逃离漏洞，通过入侵检测的机制，就可以有一个比较有效的防御。

• 定制Linux Kernel Patch，一些特殊的资源隔离或者安全漏洞，也可以为kernel打一些自身特有的patch来加以防范，但是这里的patch面临的问题是多种多样的，所以这里就不再展开细讲了。

容器运行时

=====

上述安全实践方案和措施能够很大程度的减少对外提供服务时受攻击的范围，提高容器服务的安全能力。但我们仍然想要寻找一种简单的、有效的、统一的runtime解决方法，我们把眼光投入到CNCF runtime Landscape，可以看到有多种解决方案。

简单梳理一下这些解决方案，都是按照两大标准划分的。一个就是CRI的标准，偏向于kubelet或者Kubernetes这一侧的标准。还有一侧的标准就是OCI，就是偏向于容器底层基础实现。

可以看到OCI这边有很多种实现方案，简单梳理一下，划分了一个表格：

简单介绍一下，比如有runC的方案，就是基于原生namespace的容器方案，Docker使用的，containerd直接对接的runc的方案。gVisor是谷歌开源出来的一种基于用户态的内核进程的安全沙箱技术的方案。Kata和Qemu的基于虚拟化实现安全容器，这个现在也是比较热门，使用比较广泛的一种方案。Firecracker，由AWS开源出来的，Firecracker Containerd是对接OCI标准的组件，但现在还没有完全对接OCI标准，所以这里是有所欠缺的。最后是Nabla，runnC是Nabla对接OCI实现的一个组件，Nabla是IBM开源的一套安全容器的方案，但是它跟上述的一些方案有所区别，它是一个基于unikernel的方案，把业务应用和内核完全编译在了一起，直接运行在host上面，所以可以看到它跟其他的方案不一样的就是它不能直接使用容器的镜像，需要自己编译一个带着内核的特殊镜像，所以用起来不太符合容器的标准。