安全容器

一、什么是安全容器

1.概念

安全容器是一种为应用程序提供高度隔离和安全性的技术，它可以控制应用程序访问系统资源和数据的权限，并提供虚拟化，使应用程序能够在隔离的环境中运行。安全容器的概念最早是由 FreeBSD 操作系统的开发者 Jails 提出的，他们在 2000 年左右将这一概念引入 FreeBSD 操作系统。后来，Linux 容器技术发展起来后，安全容器概念也逐渐被引入其中。

2.kubenertes

目前k8s或者docker底层容器，通常是依赖于runc，而runc的资源隔离方案底层是 Linux 容器技术。它利用 Linux 内核提供的一些隔离机制，如 namespace、cgroup、seccomp等。具体来说，namespace 用于隔离应用程序的进程空间、网络、文件系统等，cgroup 用于限制应用程序的资源使用，seccomp 用于限制应用程序对系统调用的访问。runc 利用这些机制，将应用程序运行在一个隔离的环境中，从而提高应用程序的安全性和可靠性。但在实际运行中，仍是由宿主机向容器直接提供网络、存储、计算等资源，然而容器的安全性可以概括为两点： a.不会对主机造成影响。b.不会对其他容器造成影响。Docker的不安全表现在共用内核问题、Namespace还不够完善。具体表现：

1. 资源未隔离

# 容器内部输出与宿主机一致
$ free -m 
# 看到宿主机的进程
$ top
# /dev设备未隔离:容器内查看所有设备与宿主机一致
$ ls /dev
# 如果runc容器没有隔离/sys
# 那么容器内的进程可以轻易地获取主机上的内核信息，如主机的CPU或者内存信息。
# 这意味着容器内的恶意进程可以利用这些信息来绕过安全控制，访问主机上的敏感资源或破坏主机的系统
$ ls /sys
# /proc 未完全隔离
# runc 在默认情况下不隔离 /proc，这意味着容器中的进程可以看到宿主机上的进程
$ ls /proc

2. 内核模块未隔离。

3. SELinux、time、syslog等所有现有Namespace之外的信息都未隔离。

4. Root用户未隔离（如果Root用户未隔离，容器中的进程可以通过提升权限来访问宿主机中的资源）

5. 攻击案例

• CVE-2019-5736 runC 漏洞，它能让普通用户身份运行的恶意程序渗透到宿主机，修改 runC 程序，在下次创建容器时就会调用被修改的 runC，借此，攻击者可以实现任何非法目的

二、集成安全容器有什么价值

1. 提升安全性：容器间完全隔离，容器内部无法访问其他容器内部资源。
2. 提升稳定性：因为隔离的原因，容器只能影响到自身内部无法影响到其他容器以及宿主机；
3. 更细粒度资源控制：安全容器可以提供更细粒度的资源控制，包括CPU、内存、网络等方面，从而更好地管理和控制容器的资源使用。
4. 多租户安全保障。 云原生多租户场景下，安全容器可以防止恶意租户对 host 内核的直接攻击并大幅减少机器上其他租户的风险，从而让公有云服务变得更稳定

三、安全容器相关的技术有哪些

1. gvisor Go编写的应用程序内核、虚拟机监控程序（virtual machine monitor）、内部Runsc替代runc集成到docker、用户态的内核；

机器级虚拟化-性能消耗大安全性高

规则级别虚拟化-类似runc

gvisor的虚拟化.png

2. firecracker 亚马逊AWS开源，依赖KVM，轻量级虚拟机管理器VMM，QEMU替代品，资源利用率更高，不支持所有设备类型；

什么是QEMU和firecraker

Hypervisor是什么

Hypervisor的结构

3. openeuler StratoVirt 开放原子开源基金会孵化及运营，是基于Linux内核的虚拟机（KVM）的开源轻量级虚拟化技术,轻量级的虚拟机管理器,企业级虚拟化VMM(Virtual Machine Monitor)

StratoVirt架构

StratoVirt.iSulad接入安全容器

4. QEMU 模拟计算机硬件的开源软件,可用作虚拟机管理器，功能齐全，成熟完善，支持所有设备

qemu-kvm架构图

qemu-kvm组件图

5. kata-containerd Intel开源项目合并,轻量级的容器运行时

katacontainers和传统容器(runc)区别

docker和kata-runtime

kata与k8s

kata与k8s示意图

kubelet执行create pod之后逻辑架构

kata3.x-架构

kata3.0可选的hypervisor-config

kata比runcs是GuestOS虚拟化-等效于runc加硬件虚拟化和HostOS虚拟化

四、安全容器集成方案

1.kata-container

1. 方案：

• 背景: Intel Clear Containers 的最佳部分与 Hyper.sh RunV的合并；
• 安装方式：kata-deploy(kubectl apply)、dnf软件包管理器、Snap包管理器等
• 依赖：x86_64/amd64支持Intel VT-x, AMD SVM；aarch64/arm64支持ARM Hyp
• 虚拟机管理程序：Dragonball(内置VMM)、firecraker、qemu(默认)、cloud-hypervisor等；
• 集成方式：安装kata-contianer，与k8s对接支持两种CRI实现，分别是CRI-O和containerd；

2. 优点

• 多租户安全保障：防止恶意租户对 host 内核的直接攻击影响其他租户；
• 可信&不可信容器混合部署：runC容器、安全容器可以同时部署在同一个宿主机之中；
• Configurable Hypervisor，支持多种虚拟机监控程序，默认支持的是qemu，也可以用firecracker、Dragonball;
• 社区：社区活跃，方案成熟，阿里云、蚂蚁和intel共同推动2.0架构，提升多租隔离能力及可观测性；
• 安装：方式多样且k8s deploy方便快捷；
• 集成：与k8s集成方便快捷,支持CRI-O也可以支持containerd，系统部署复杂度；
• 兼容性：应用兼容性好
• 安全性：非常可靠，使用Intel VT-x和AMD SVM等硬件虚拟化技术支持硬件级别的隔离，使用SELinux、AppArmor等安全模块实现一系列安全机制；

3. 缺点

• 性能问题：由于需要额外的虚拟化层，kata-containerd的性能较runc略低。
• 复杂性：kata-containerd需要额外的虚拟化层，使得整个系统更加复杂，增加了管理和维护的难度。
• 开销：开销较大，启动速度较慢，阿里云官方文档说社区版kata需要500ms而ACK安全沙箱v2约150ms。
• IO比runc慢

2.gvisor

1. 方案

• 背景：gvisor是google发布的一个安全容器，底层是基于安全模块seccomp、SELinux和 AppArmor，代理系统系统调用实现安全隔离，号称合并的用户态内核和VMM的；
• 安装方式：与Containerd集成（containerd/config.toml和k8s.spec.runtimeClassName=gvisor）、Minikube集成；
• 依赖：不依赖硬件虚拟化支持（Intel的Intel VT-x技术，AMD的AMD SVM技术）不依赖kvm，可以在虚拟机上虚拟化，与runc一样依赖Namespaces\cgroup等，只是增加了一层封装实现虚拟机模拟硬件等；

2. 优点

• 用户态内核，支持虚拟机上虚拟化；
• 启动速度更快和占用资源更小：不需要虚拟出硬件设备、安装 Guest 操作系统；
• 应用执行性能上：与kata-containers不分伯仲；

3. 缺点

• 代理系统调用实现隔离，当系统调用繁重时候，性能较差；
• 目前并未实现每个系统调用、/proc文件或/sys文件，因此可能会出现一些不兼容问题，通过兼容性测试的应用；
• 稳定性风险：相对新的容器技术(初版release-20190304)，gvisor可能存在一些稳定性问题和未解决的bug，需要持续的维护和更新来保持稳定性；
• 系统调用密集的应用，比如重I/O或者重网络的应用，gVisor 就会因为需要频繁拦截系统调用而出现性能急剧下降.
• 网络IO性能更差

3.在hypervisor和CRI implements做最佳选择

安全容器方案

4.kata和stratoVirt集成方案如何集成

5.kata和firecraker的性能

hypervisor	启动速度	内存消耗	IO性能	社区
qemu	500ms 阿里云文档 0.7s 参考	131MB 参考		03年推出7.8k
firecracker	125ms ,单机秒开150 microVMs	<5MB 测试为3MB	比qemu差点	18年推出21.5k star
statovirt	microvm 50ms	< 4MB		18年推出 98 star
阿里云ACK安全沙箱	150ms
Cloud Hypervisor	100ms	13MB		2.7k star

6.gvisor和kata+qemu的对比

1. Memory Footprint内存占用:kata 70mb、gvisor 20mb；
2. Boot time启动时间:gvisor 0.45s、shimv2+kata 0.7s；
3. CPU/Memory Performance CPU和内存的性能:gvisor和kata & qemu 几乎一致；
4. IO性能:部分场景gvisor和kata&qemu几乎一致，部分场景kata&qemu表现更优秀；
5. Networking Performance网络性能:kata性能与gvisor差距明显，kata性能好非常多；
6. 真实案例Nginx:kata的QPS能达到1.4w,gvisor的QPS是309;Transfer rate传输速率应该是12,127kb,而gvisor是255kb；
7. 真实案例Redis之下，kata的QPS可以达到120,000,gvisor的不超过20,000;

总结:

gvisor启动更快内存消耗小，是兼容性差（很多系统调用还未实现），网络IO性能表现非常差，在系统调用频繁的情况下性能非常差；

7. firecraker的性能

1. Firecracker MicroVM的启动时间大约为100毫秒，而QEMU的在200毫秒以上；
2. Firecracker内存开销非常低，每个MicroVM约为3MB，而QEMU在131MB左右；
3. Firecraker的IO性能约为QEMU的1/4;
4. firecraker不支持所有的设备类型；
5. 限于firecracker本身功能过于简单，因为其设计之初就是追求最少的设备、最简洁的功能，firecracker目前很多k8s的功能还不支持，比如volume、secret、configmap等。如果应用比较复杂，对运行环境的要求比较高，就只能使用qemu vm

8. 阿里云的安全容器性能

1. 安全沙箱号称启动约150ms，而kata-container的启动时间500ms；

五、如何集成到k8s

1. 安装方式

使用containerd集成的方式集成kata，在各个宿主机安装kata，使用runtimeClass的方式注册到k8s之中

kind: RuntimeClass
apiVersion: node.k8s.io/v1alpha1
metadata:
    name: native 
spec:
    runtimeHandler: runc
---
kind: RuntimeClass
apiVersion: node.k8s.io/v1alpha1
metadata:
    name: kata-containers
spec:
    runtimeHandler: kata-containers

runtimeHandler对应containerd的handler

# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]

# 示例配置
# /etc/containerd/config.yml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
  runtime_type = "io.containerd.kata.v2"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options]
    ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration-qemu.toml"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  runtime_type = "io.containerd.runc.v2"

tips:如果各节点的运行时环境不一致，可通过scheduling限制仅调度到支持该 RuntimeClass 的节点上。如未设置 scheduling，默认所有节点均支持此 RuntimeClass

2. 如何使用

声明式创建对象的时候，声明runtimeClass的方式创建对象

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: sandboxed-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-nginx
  template:
    metadata:
      labels:
        app: native-nginx
    spec:
      runtimeClassName: native # runtimeClassName 字段选定运行时使用runc
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          protocol: TCP

3. 如何验证

进入容器之中，执行 uname -a 查看内核，如果与宿主机不一致表示当前已经是安全容器之中

Q&A

1. runc底层原理

• namespace 用于隔离应用程序的进程空间、网络、文件系统等
• cgroup 用于限制应用程序的资源使用
• seccomp 用于限制应用程序对系统调用的访问

2. kata+firecraker 和 kata+StratoVirt 哪个性能更好

3. iSula比Docker强没错，但是iSula和Containerd比呢

kata就是一个OCI

4. 查看kata-runtime的运行日志

$ tail -f /var/log/messages | grep kata-runtime
$ tail -f /var/log/messages | grep kata-runtime

5. 如何查看containerd的容器消耗

# docker 查看容器消耗的内存和CPU
$ docker stats $containerdID

6. 如何查看containerd当前容器列表的虚拟化方式

# containerd 罗列容器
$ ctr c ls

7. containerd运行一个容器

# 运行cni分配终端running后移除容器
$ ctr run --runtime io.containerd.kata.v2 --cni -t --rm docker.io/library/busybox:latest hello sh

8. journalctl查看系统服务日志

# 查看containerd日志
$ journalctl -ucontainerd -f

相关资料

• https://firecracker-microvm.github.io/

• https://gvisor.dev/

• https://katacontainers.io/

• https://www.qemu.org/

• https://docs.openeuler.org/zh/docs/22.03_LTS_SP1/docs/StratoVirt/

• https://www.linux-kvm.org/page/Main_Page

• https://libvirt.org/

• https://kubevirt.io/

• https://selinuxproject.org/page/Main_Page

• 如何安装启动StratoVirt

• https://gitee.com/openeuler/stratovirt

• stratovirt设计

• 华为 | 基于Rust的下一代虚拟化平台-StratoVirt

• 已有Qemu了，为什么还要StratoVirt

• Qemu架构图

• KVM & Qemu &

• Qemu架构图

• kata如何选择hypervisors

• kata博客架构图

• run kata containers with kubernetes

• 迈向Kata 3.0|走进开箱即用的安全容器体验之旅|龙蜥技术

• 阿里云Severeless产品背后的kataContainers

• Kata Containers 在百度智能云的应用实践

• 阿里云官方文档-容器安全解决方案

• 阿里云官方文档-云原生安全容器解决方案

• 阿里云官方文档-安全容器底层的安全沙箱（runV）容器

• 阿里云官方文档-ACK安全沙箱和社区KataContainers对比

• InfoQ-安全容器在阿里巴巴的应用和实践

• gVisor:谷歌发布的一个用于提供安全隔离的轻量级容器运行时沙箱

• gvisor Containerd Quick Start

• Virtio：一种Linux I/O虚拟化框架

• 极客时间:kata-containers与gvisor实现原理

• kata-containers官方文档：kata与gvisor性能

• Docker 真的要被 Kubernetes 社区剔除了吗

• docker与k8s的发展史

• CRI架构图

• Firecracker性能标准

• Firecraker的缺点

• k8s官方手册-容器运行时

• github.com/containerd

• zhihu/什么是 Service Mesh

• PhilCalcado/Pattern: Service Mesh

• 官网运行时container-runtimes

• csdn剖析容器docker运行时-说的太细致了

• csdn之IaaS/PaaS/SaaS/DaaS的区别-说的太好了

• 知乎/container之runc

• 从零开始入门 K8s | Kata Containers 创始人带你入门安全容器技术

• 如何在 Kubernetes 集群中集成 Kata

• Docker，containerd，CRI，CRI-O，OCI，runc 分不清？看这一篇就够了 - 写的太好了

• huweihuang/Kata-container简介

• kata-containd和docker集成

• 如何给docker添加runtime支持

• 博客园-KataContainers和Docker的集成

• https://www.qemu.org/

• sandbox interface because it conflicts with existing route

• 虚拟化研究中KVM和QEMU的区别-这个图画的很哇塞哦

• k8s官方讲解有多少种CRI

• 非常细致描述kata的优势

• 容器在k8s是什么

轻量级的虚拟化技术，可以打包应用程序及其依赖项，使其更易于部署和管理
k8s支持多种容器运行时（Container Runtime），包括Docker、containerd、CRI-O等

• 容器运行时Container Runtime是什么意思

一种软件，其主要任务是负责在操作系统上启动和管理容器
容器运行时通常通过调用操作系统提供的系统调用 - 来创建和管理容器
一般和容器编排工具（例如Kubernetes）协同工作，实现容器的自动化部署、扩缩容等
常见容器运行时有：Docker容器引擎、rkt、containerd等

• Kubernetes中的容器可能会有哪些安全风险

1. 容器之间共享主机系统的资源,可能会通过共享文件或进程来获取其他容器中的敏感信息
2. 容器的容量限制不够严格
3. 容器镜像来源不可信
4. 容器网络安全风险,比如需要访问外部网络或者其他容器
5. 容器数据持久化缺少加密
6. Kubernetes容器默认以高权限运行，容器内进程的文件系统和主机文件系统是共享的

• 模拟docker的容器A非法访问容器B的资源
• NetworkNamespace是在Linux内核中实现的一种机制，用于隔离网络资源，例如网络接口、路由表和iptables规则等
• kata是什么
• 容器逻辑上分割，物理上的资源区隔的设计是什么样的
• kubernetes的安全策略，如容器隔离、网络策略、RBAC设计是什么样的
• iSula是什么
• iSula+StratoVirt安全容器是什么
• 在容器执行top命令看到宿主机进程，为什么
• containerd和docker什么关系，有架构图吗
• runc、cri、运行时是什么
• 容器网络安全是怎么样的
• k8s的设计的架构图
• docker架构图
• Istios是第二代Service Mesh的代表
• Service Mesh服务网格是一种用于解决微服务架构中服务之间通信的问题的技术
• namespace和cgroups标准是什么
• OCI(Open Container Initiative)(开放容器计划)是什么涉及哪些内容
• Kubernetes的CRI(Container Runtime Interface)的容器运行时接口是什么意思
• shim的设计:作为适配器将自身容器运行时接口适配到 Kubernetes 的 CRI 接口(dockershim就是Kubernetes对接Docker到CRI接口)
• CGroup是Control Groups限制\记录\隔离进程组所使用的物理资源
• Name Space是什么
• Busy Box是什么
• k3s是什么
• Kernel是什么
• 如何添加并使用docker的runtime和查看当前docker支持的runtime
• docker使用kata runtime 抛出异常 cannot program address in sandbox interface because it conflicts with existing route
• Qemu是什么
• KVM是什么
• KVM 要求 CPU 支持虚拟化扩展，例如 Intel VT 或 AMD-V。如果您的 CPU 不支持这些扩展，则无法使用 KVM
• Kata Containers如何配置使用QEMU
• Kata Runtime使用Firecracker
• QEMU path (/usr/bin/qemu-kvm) does not exist

$ yum install -y qemu

• Fedora 和 Centos 和 ky10.aarch64是什么关系
• modprobe是干嘛的
• docker run --runtime kata-runtime && Could not access KVM kernel module
• 怎么判断cpu是否支持KVM
• linux的命名空间是什么

命名空间是Linux内核中的一个概念，它可以将不同的系统资源隔离开来，比如网络、进程空间等。
通过将容器连接到特定的网络命名空间中，可以实现容器与特定网络资源的隔离和互通

• kata-containerd 和 kvm 是什么关系

• kata-containerd 可以不依赖kvm吗

• 使用docker时候用的runtime是kata-runtime 但是不想依赖kvm怎么实现

• kata containerd 怎么运行需要什么条件

• KataContainers和Docker如何集成

• kvm_intel是干嘛的

• 如何判断当前aarch64支持ARM Hyp

• kata runtime可以不需要kvm吗，怎么实现

• x86_64, amd64 Intel VT-x, AMD SVM 是什么意思

• aarch64 ("arm64") ARM Hyp 是什么意思

• mac 怎么判断 arm64（aarch64）架构是否支持ARM Hypervisor

# 输出1表示支持虚拟化
$ sysctl kern.hv_support

• kvm 和 ARM Hypervisor什么关系

KVM和ARM Hypervisor都是虚拟化技术，用于在处理器上创建虚拟化环境。

KVM是用于x86架构的开源虚拟化解决方案，而ARM Hypervisor是用于ARM架构的虚拟化解决方案。

在ARM架构中，ARM Hypervisor被用于虚拟化环境和资源，它允许多个操作系统同时运行在单个ARM处理器上，每个操作系统都在自己的虚拟机中运行。
ARM Hypervisor通过使用虚拟地址空间映射等技术来隔离不同的虚拟机之间的资源，从而保证每个虚拟机的安全性和独立性。

与此类似，KVM也是一种虚拟化解决方案，它可以在x86架构的处理器上运行多个虚拟机，并将物理资源映射到虚拟机中。
KVM通过模拟多种硬件设备，如网络适配器和存储控制器等，为虚拟机提供与物理主机相同的环境，从而保证虚拟机的稳定性和性能。

总之，KVM和ARM Hypervisor都是虚拟化技术，它们可以在不同的架构上将物理主机资源虚拟化为多个虚拟机，并支持多个操作系统同时运行。
相比于x86架构，ARM Hypervisor在ARM架构上提供了更高效和安全的虚拟化环境。

• kvm 和 Intel VT-x, AMD SVM是什么关系

Intel VT-x和AMD SVM是虚拟化技术的硬件支持，可以使操作系统在虚拟机中以更高效率的方式运行。
kvm是一种基于虚拟化技术的虚拟机监视器，可以在支持Intel VT-x或AMD SVM的处理器上运行。
kvm通过硬件虚拟化技术实现虚拟化，提供更高效的虚拟化性能。

因此，Intel VT-x和AMD SVM是支持kvm运行的基础。

• 虚拟化研究中KVM和QEMU的区别

QEMU（Quick Emulator）是一个独立的开源虚拟机软件，纯软件的实现（处理器虚拟化、内存虚拟、虚拟设备模拟）

Qemu利用KVM提供的LibKvm应用程序接口，通过ioctl系统调用创建和运行虚拟机

QEMU在上层，KVM在下层

KVM(Kernel-based Virtual Machine)是基于虚拟化扩展（Intel VT或AMD-V）的X86硬件平台实现的Linux的全虚拟化解决方案

KVM是x86的东西

• 网桥是什么

网络设备，连接多个网络。
转发不同网络之中的数据流。
工作在OSI模型的第二层：数据链路层
通过物理地址（MAC地址）识别网络设备来传递数据包

• 网段是什么

网络地址范围 (表示方式：IP地址和子网掩码)；
同一网段的设备可互相通信
不同网段需要路由器等设备才可痛心

• rootfs是什么

• Guest Kernel是什么

• Virtio是什么

• 阿里巴巴的ACK是什么意思

阿里的ACK的全称是Alibaba Cloud ACK（Alibaba Cloud Container Service for Kubernetes）。

课题方向

1. 容器哪里不安全了
2. 目前的解决方案是什么样的
3. 解决方案的使用怎样可达到更好的效果
4. 一些常见的兼容性、性能测试覆盖一下

Containerd 实现了 Kubernetes 容器运行时接口 (CRI) BuildKit 是一种开源工具，它从 Dockerfile 获取指令并“构建”Docker 映像 OCI (Open Container Initiative) 开放容器计划（容器规范的开放标准） CRI (Container Runtime Interface) 容器运行时接口，定义了 Kubernetes 与容器运行时之间的接口和协议 CRI-O 是实现了CRI和OCI，实现 OCI 和 CRI，等于是containerd

架构图

gVisor和Kata Containers都是用于提供容器运行时隔离性的开源技术选项。以下是它们各自的优缺点：

gVisor的优点：

• gVisor 使用了一个特殊的沙箱机制，可以提供更高的隔离性和安全性。
• gVisor可以在Linux容器内运行，而无需对宿主机进行特殊设置。
• gVisor的性能比Kata Containers更快。

gVisor的缺点：

• gVisor还是一个比较新的项目，尚未被广泛测试和采用。
• gVisor需要的内存和CPU资源比Kata Containers更多。
• 系统调用频繁的情况下gvisor的性能差

Kata Containers的优点：

• Kata Containers运行在轻量级虚拟机中，可以提供与传统虚拟机相似的隔离性和安全性。
• Kata Containers基于OCI标准，可以无缝地与Docker等容器工具集成。
• Kata Containers比gVisor更易于部署和使用。
• Kata Containers的启动时间通常在几百毫秒到一秒左右。

Kata Containers的缺点：

• Kata Containers的启动速度比gVisor慢（但kata速度仍然非常快，通常在毫秒级别），因为它需要启动轻量级虚拟机。
• 由于使用了轻量级虚拟机，Kata Containers的性能比gVisor略低。

需要注意的是，以上优缺点只是大概的总结，实际的情况可能会因特定的使用场景和需求而发生变化。