如何在 Kubernetes 中运行不受信任的容器-51CTO.COM

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: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
    name: #RuntimeClass Name
handler: #container runtime for example: runc
overhead:
    podFixed:
        memory: "" # 64Mi
        cpu: "" # 250m
scheduling:
  nodeSelector:
    <key>: <value> # container-rt: gvisor

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-start

启动机器后，验证所有组件是否已启动并运行：

vagrant ssh master

kubectl get nodes

NAME      STATUS   ROLES                  AGE     VERSION

master    Ready    control-plane,master   7m59s   v1.21.0

worker1   Ready    <none>                 5m50s   v1.21.0

worker2   Ready    <none>                 3m51s   v1.21.0

在 worker1 上安装gVisor：

ssh worker1 # Vagrant default password: vagrant

sudo su

安装最新的 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
)

FINISHED --2022-04-28 07:24:44--

Total wall clock time: 5.2s

Downloaded: 4 files, 62M in 3.1s (20.2 MB/s)

runsc: OK

containerd-shim-runsc-v1: OK

配置容器运行时：

cat <<EOF | sudo tee /etc/containerd/config.toml
version = 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"
EOF

重启容器服务：

sudo systemctl restart containerd

为 gVisor 安装 RuntimeClass：

cat <<EOF | kubectl apply -f -
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
EOF

验证：

vagrant@master:~$ kubectl get runtimeclass

NAME     HANDLER   AGE

gvisor   runsc     17s

使用 gVisor RuntimeClass 创建一个 Pod：

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: nginx-gvisor
spec:
  runtimeClassName: gvisor
  containers:
  - name: nginx
    image: nginx
EOF

验证 Pod 是否正在运行：

kubectl get pod nginx-gvisor -o wide

vagrant@master:~$ kubectl get pod nginx-gvisor -o wide

NAME           READY   STATUS    RESTARTS   AGE   IP                NODE      NOMINATED NODE   READINESS GATES

nginx-gvisor   1/1     Running   0          31s   192.168.235.129   worker1   <none>           <none>

有关更新信息，请关注官方文档。https://gvisor.dev/docs/user_guide/install/

结论

我们已经看到当前的容器技术存在弱隔离问题。快速修补容器和最低安全上下文特权等常见做法可以有效限制攻击面。我们甚至应该开始像上面的教程那样实施运行时安全措施，因为现在可能有多个容器运行时。

当然，这不是每个人都需要的东西，但是当您想要运行不受信任的容器而不以任何方式影响主机时，它肯定会派上用场。

假设你是一个容器托管服务，在同一台主机上启动不同客户的容器。你会因为共享上下文而损害其他客户吗？开始思考如何缓解这些问题。