IT 世界每天都在越来越多地采用基于容器的运行基础架构 。但是不受 ，每个人都不清楚优点 ，信任缺点甚至局限性 。运行
考虑到即使是不受大公司也在靠近基于容器的基础设施 ，但是信任可能的攻击区域和数据泄露的潜在影响却无人在意 。
Docker（containerd）和 LXC 等技术并不是运行真正孤立的系统 ，因为它们与托管的模板下载不受操作系统共享相同的 Linux 内核 。
对于潜在的信任攻击者来说 ，在大公司内启动他们的运行容器是一个千载难逢的机会 。但容器技术自身能让我们轻松自卫吗 ？不受
当前的容器技术已经重复了很多次 ，容器是信任一种打包 、共享和部署应用程序的运行新方式 ，而不是不受所有功能都打包在一个软件或操作系统中的服务器租用单一应用程序 。
目前 ，信任容器没有利用任何新的东西 ，但它们是在 Linux 命名空间和 cgroup 之上创建的演变。命名空间创建了一个虚拟和隔离的用户空间 ，并为应用程序提供其系统资源的隔离 ，例如文件系统、网络和进程 。这种抽象允许应用程序独立启动 ，而不会干扰在同一主机上运行的其他应用程序 。香港云服务器
所以 ，多亏了命名空间和 cgroup 的结合 ，我们绝对可以在一个隔离的环境中启动许多在同一主机上运行的应用程序 。
容器与虚拟机很明显 ，与虚拟机环境相比 ，容器技术解决了在隔离性 、可移植性和精简架构方面的问题 。但我们不要忘记，虚拟机允许我们隔离我们的应用程序，尤其是在内核级别 ，亿华云因此黑客逃离容器并破坏系统的风险远高于逃离虚拟机 。
大多数 Linux 内核漏洞可能适用于容器 ，这可能允许它们升级和破坏受影响的命名空间以及同一操作系统中的其他命名空间 。
这些安全问题导致研究人员尝试从主机创建真正分离的命名空间 。具体称为“沙盒” ，现在有几种解决方案可以提供这些功能 ：gVisor 或例如 Kata Containers 。
Kubernetes 中的容器运行时我们可以在容器编排器 Kubernetes 中更深入地研究这类技术 。
Kubernetes 使用组件 kubelet 来管理容器 。我们可以将其定义为负责提供给它的规范并准时准确地执行其操作的船长。免费模板
Kubelet 采用 pod 规范并使其在分配给它们的主机上作为容器运行 ，并且可以与任何容器运行时交互 ，只要它符合 OCI 标准（其实现是 RunC）
容器运行时的工作原理
RunC最初嵌入到Docker架构中 ，于 2015 年作为独立工具发布 。它已成为 DevOps 团队可以用作容器引擎的一部分的常用的 、标准的 、跨功能的容器运行时 。
RunC 提供了与现有低级 Linux 特性交互的高防服务器所有功能 。它使用命名空间和控制组来创建和运行容器进程 。
在下面的段落中，我们将介绍运行时类和核心元素 。还有一个 RuntimeClass 处理程序，其默认值为 RunC（对于使用 containerd 作为容器运行时的 Kubernetes 安装） 。
RuntimeClass顾名思义 ，运行时类允许我们使用各种容器运行时进行操作 。2014 年 ，Docker 是 Kubernetes 上唯一可用的运行时容器 。从 Kubernetes 1.3 版开始，添加了与 Rocket (RKT) 的兼容性 ，最后在 Kubernetes 1.5 中 ，引入了容器运行时 Iterface (CRI)，它具有标准接口和所有容器运行时的可能性 ，您可以直接与此接口标准省去了开发者适应各类容器运行时的麻烦和担心版本维护的麻烦。
事实上 ，CRI 允许我们将容器运行时部分与 Kubernetes 分离 ，最重要的是 ，允许 Kata Containers 和 gVisor 等技术以 containerd 的形式连接到容器运行时 。
在 Kubernetes 1.14 中 ，RuntimeClass 再次作为内置集群资源引入，其核心是处理程序属性。
处理程序是指接收容器创建请求的程序 ，对应于容器运行时 。
复制kind: RuntimeClassapiVersion: node.k8s.io/v1metadata:
name: #RuntimeClass Namehandler: #container runtime for example: runcoverhead:
podFixed:
memory: "" # 64Mi cpu: "" # 250mscheduling:
nodeSelector:
<key>: <value> # container-rt: gvisor1.2.3.4.5.6.7.8.9.10.11.12. handler 字段指向要使用的特定容器运行时或配置 。声明开销允许集群（包括调度程序）在做出有关 Pod 和资源的决策时考虑它 。通过使用这些字段 ，您可以使用此 RuntimeClass 指定运行 pod 的开销 ，并确保在 Kubernetes 中考虑这些开销。调度字段用于确保 Pod 被调度在正确的节点上 。默认情况下 ，如果我们有一个带有 Docker 或 containerd 的集群，我们的处理程序是 runc ，但如果我们使用 gVisor ，它将是 runc。
在 Kubernetes 中使用 gVisor 隔离 Linux 主机和容器现在我们将了解如何在 Kubernetes 集群中拥有多个容器运行时 ，并为敏感工作负载选择更严格的容器运行时。
在本教程中 ，我使用了之前的项目 ，在该项目中我使用 containerd 安装了 Kubernetes 集群 。
https://github.com/alessandrolomanto/k8s-vanilla-containerd
初始化 Kubernetes 集群 ：
复制make vagrant-start1.启动机器后 ，验证所有组件是否已启动并运行 ：
复制vagrant ssh masterkubectl get nodes1.2.3. 复制NAME STATUS ROLES AGE VERSIONmaster Ready control-plane,master 7m59s v1.21.0worker1 Ready <none> 5m50s v1.21.0worker2 Ready <none> 3m51s v1.21.01.2.3.4.5.6.7.在 worker1 上安装gVisor ：
复制ssh worker1 # Vagrant default password: vagrantsudo su1.2.3.安装最新的 gVisor 版本 ：
复制(
set -e ARCH=$(uname -m)
URL=https://storage.googleapis.com/gvisor/releases/release/latest/${ ARCH} wget ${ URL}/runsc ${ URL}/runsc.sha512\\
${ URL}/containerd-shim-runsc-v1 ${ URL}/containerd-shim-runsc-v1.sha512 sha512sum -c runsc.sha512\\
-c containerd-shim-runsc-v1.sha512 rm -f *.sha512 chmod a+rx runsc containerd-shim-runsc-v1 sudo mv runsc containerd-shim-runsc-v1 /usr/local/bin)1.2.3.4.5.6.7.8.9.10.11.12. 复制FINISHED --2022-04-28 07:24:44--Total wall clock time: 5.2sDownloaded: 4 files, 62M in 3.1s (20.2 MB/s)
runsc: OKcontainerd-shim-runsc-v1: OK1.2.3.4.5.6.7.8.9.配置容器运行时 ：
复制cat <<EOF | sudo tee /etc/containerd/config.tomlversion = 2[plugins."io.containerd.runtime.v1.linux"]
shim_debug = true[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v2"[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
runtime_type = "io.containerd.runsc.v1"EOF1.2.3.4.5.6.7.8.9.重启容器服务 ：
复制sudo systemctl restart containerd1.为 gVisor 安装 RuntimeClass：
复制cat <<EOF | kubectl apply -f -apiVersion: node.k8s.io/v1beta1kind: RuntimeClassmetadata:
name: gvisorhandler: runscEOF1.2.3.4.5.6.7.验证：
复制vagrant@master:~$ kubectl get runtimeclassNAME HANDLER AGEgvisor runsc 17s1.2.3.4.5.使用 gVisor RuntimeClass 创建一个 Pod ：
复制cat <<EOF | kubectl apply -f -apiVersion: v1kind: Podmetadata:
name: nginx-gvisorspec:
runtimeClassName: gvisor containers:
- name: nginx image: nginxEOF1.2.3.4.5.6.7.8.9.10.11.验证 Pod 是否正在运行 ：
复制kubectl get pod nginx-gvisor -o wide1. 复制vagrant@master:~$ kubectl get pod nginx-gvisor -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-gvisor 1/1 Running 0 31s 192.168.235.129 worker1 <none> <none>1.2.3.4.5.有关更新信息 ，请关注官方文档 。https://gvisor.dev/docs/user_guide/install/
结论我们已经看到当前的容器技术存在弱隔离问题 。快速修补容器和最低安全上下文特权等常见做法可以有效限制攻击面 。我们甚至应该开始像上面的教程那样实施运行时安全措施 ，因为现在可能有多个容器运行时 。
当然 ，这不是每个人都需要的东西，但是当您想要运行不受信任的容器而不以任何方式影响主机时 ，它肯定会派上用场 。
假设你是一个容器托管服务 ，在同一台主机上启动不同客户的容器 。你会因为共享上下文而损害其他客户吗？开始思考如何缓解这些问题 。