containerd中文翻译系列(二十一)用户命名空间

支持用户命名空间

Kubernetes 自 v1.25 起支持使用用户命名空间运行 pod。本文档解释了

containerd 对该功能的支持。

什么是用户命名空间?

用户命名空间将容器内运行的用户与主机内的用户隔离开来。

在容器中以 root 用户身份运行的进程可以在主机中以不同的(非 root)用户身份运行。换句话说,进程在用户命名空间内的操作具有完全权限,但在命名空间外的操作则没有权限。

您可以使用此功能来减少受损容器对主机或同一节点中其他损害。有几个被评为 "高度 "或 "严重 "的安全漏洞在用户命名空间处于活动状态时无法被利用。预计用户命名空间也将缓解一些未来的漏洞。

有关用户命名空间的高级介绍,请参阅[kubernetes 文档]kube-intro

栈要求

Kubernetes 的实现在 1.27 版中进行了重新设计,因此,Kubernetes 1.27 之前和之后的版本要求有所不同。

请注意,如果尝试在 containerd 1.6 或更早版本中使用用户命名空间,pod.spec 中的 `hostUsers:false "设置将被无声地忽略

Kubernetes 1.25 和 1.26

  • Containerd 1.7
  • 您可以使用 runc 或 crun 作为 OCI 运行时:
    • runc 1.1 或更高版本
    • crun 1.4.3 或更高版本

也可以使用 containerd 2.0 或更高版本,但[要求与 Kubernetes 1.27 及更高版本相同],除了Linux 内核。请记住,所有要求都适用包括支持 idmap 挂载的文件系统。您可以使用 Linux版本:

  • Linux 5.15:你将受到 [containerd 1.7 存储和延迟的
    限制](#containerd 1.7 存储和延迟的 限制),因为它不支持 overlayfs 的 idmap 挂载。
  • Linux 5.19 或更高版本(推荐):它不受 [containerd 1.7 存储和延迟限制](#Limitations
    限制,因为 overlayfs 在此内核版本上开始支持 idmap 挂载。

Kubernetes 1.27 或更高版本

  • Linux 6.3 或更高版本
  • Containerd 2.0 或更高版本
  • 可使用 runc 或 crun 作为 OCI 运行时:
    • runc 1.2 或更高版本
    • crun 1.9 或更高版本

此外,pod 中的卷所使用的所有文件系统都需要内核支持 idmap挂载。Linux 6.3 中支持 idmap 挂载的常用文件系统有 btrfsext4xfs、fattmpfsoverlayfs

kubelet 负责向容器填充一些文件(如 configmap、secret 等)。该路径中使用的文件系统也需要支持 idmap 挂载。请参阅Kubernetes文档 获取更多信息。

使用用户命名空间创建 Kubernetes pod

首先检查你的 containerd、Linux 和 Kubernetes 版本。如果这些都没问题,那么就不需要对 conntainerd 进行特殊配置。你只需按照 Kubernetes网站中的步骤即可。

限制

你可以查看 Kubernetes 的限制 此处。请注意,不同的Kubernetes 版本有不同的限制,请务必查看您正在使用的 Kubernetes 版本的网站

不同的 containerd 版本也有不同的限制,本节将重点介绍这些限制。

containerd 1.7

containerd 1.7 中存在的一个限制是,它需要更改容器镜像中每个文件和目录的所有权。

这意味着它会产生存储开销,因为每次创建 Pod 时,容器镜像的大小都会重复(译者:没明白)。而且会严重影响容器启动延迟,因为进行这样的复制也需要时间。

您可以将 /sys/module/overlay/parameters/metacopy切换为 Y,以减少这一限制。

这将大大减少存储和性能开销,因为只有容器镜像中每个文件的 inode

而不是文件内容。这意味着存储空间,而且速度更快。不过,这也不是万能的。

如果要更改元数据拷贝参数,请确保更改方式在重启时具有持久性。您还应注意,此设置将用于所有容器,而不仅仅是启用了用户命名空间的容器。这将影响您手动拍摄的所有快照(如果您碰巧这样做)。在这种情况下,请确保在创建和恢复快照时使用相同的 /sys/module/overlay/parameters/metacopy 值。

containerd 2.0 及以上版本

containerd 1.7 中的存储和延迟限制在容器 2.0 及以上版本中不存在、如果使用覆盖快照器(默认情况下使用)。它根本不会占用更多存储空间、而且没有启动延迟。

这是通过将内核特性 idmap和容器 rootfs(容器镜像一起 挂载。这允许覆盖文件系统以不同的 UID/GID 显示镜像,而无需复制文件或 inodes,只需使用绑定挂载即可。

默认情况下,Containerd 将拒绝创建带有用户命名空间的容器。快照器和运行的内核不支持 overlayfs 的 idmap 挂载,则 Containerd 默认会拒绝创建带有用户名称空间的容器。 这是为了确保在使用昂贵的 chown 之前(在存储和 pod 启动延迟方面),确保您了解其影响并决定opt-in。请阅读 containerd 1.7 限制中的的解释。

如果你的内核不支持 overlayfs snapshotter 的 idmap 挂载,你会看到一个错误:

复制代码
failed to create containerd container: snapshotter "overlayfs" doesn't support idmap mounts on this host, configure `slow_chown` to allow a slower and expensive fallback

从 5.19 版开始,Linux 支持在 overlayfs 上挂载 idmap。

你可以通过在配置中的 overlayfs快照器部分添加 slow_chown 字段,就可以选择慢速 chown:

复制代码
  [plugins."io.containerd.snapshotter.v1.overlayfs"]
    slow_chown = true

请注意,只有 overlayfs 用户需要选择使用慢速 chown,因为只有它才是containerd 提供的更好的选择(在containerd 中只有 overlayfs 快照器支持 idmap 挂载)。如果你使用其他快照器。如果您使用另一个快照器,您将返回到昂贵的 chown,而无需opt-in。

不过,你可以仔细检查你的容器是否为容器镜像是否使用了 idmap 挂载:

复制代码
mount | grep overlay

你应该在 lowerdir 参数中看到对 idmap 挂载的引用,在本例中,我们可以看到

idmapped":

复制代码
overlay on / type overlay (rw,relatime,lowerdir=/tmp/ovl-idmapped823885363/0,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/1018/fs,workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/1018/work)

使用 ctr 创建包含用户命名空间的容器

你也可以使用 ctr 创建带有用户命名空间的容器。这比较低级,请注意。

按照 此处 的说明创建一个 OCI bundle。然后,将 UID/GID 更改为 65536:

复制代码
sudo chown -R 65536:65536 rootfs/

复制 this config.json 并将 XXX-path-to-rootfs 替换为刚刚授权的rootfs的绝对路径。

然后创建并启动容器:

复制代码
sudo ctr create --config <path>/config.json userns-test
sudo ctr t start userns-test

这将在容器内打开一个 shell。你可以运行这个,以验证你是否在一个用户命名空间内:

复制代码
root@runc:/# cat /proc/self/uid_map
         0      65536      65536

输出结果应完全相同。

相关推荐
阿里云云原生2 小时前
Higress MCP 服务管理,助力构建私有 MCP 市场
云原生
zzywxc7873 小时前
云原生 Serverless 架构下的智能弹性伸缩与成本优化实践
云原生·架构·serverless
KubeSphere 云原生4 小时前
Higress 上架 KubeSphere Marketplace,助力企业构建云原生流量入口
云原生
AKAMAI9 小时前
在Akamai平台上进行VOD转码的参考架构
后端·云原生·云计算
2401_8368365921 小时前
k8s配置管理
云原生·容器·kubernetes
澜兮子21 小时前
k8s-服务发布基础
云原生·容器·kubernetes
小安运维日记21 小时前
CKS认证 | Day4 最小化微服务漏洞
安全·docker·微服务·云原生·容器·kubernetes
2401_8368365921 小时前
k8s服务发布进阶
云原生·容器·kubernetes