Podman和用户名字空间：天作之合

在容器中，你希望在许多容器之间共享基本镜像。上面的每个示例中使用了 Fedora 基本镜像。Fedora 镜像中的大多数文件都由真实的 UID=0 拥有。如果我在此镜像上使用用户名称空间 0:100000:5000 运行容器，默认情况下它会将所有这些文件视为 nobody 所拥有，因此我们需要移动所有这些 UID 以匹配用户名称空间。多年来，我想要一个挂载选项来告诉内核重新映射这些文件 UID 以匹配用户命名空间。上游内核存储开发人员还在继续研究，在此功能上已经取得一些进展，但这是一个难题。

由于由 Nalin Dahyabhai 领导的团队开发的自动 chown 内置于容器/存储中，Podman 可以在同一镜像上使用不同的用户名称空间。当 Podman 使用容器/存储，并且 Podman 在新的用户命名空间中首次使用一个容器镜像时，容器/存储会 “chown”（如，更改所有权）镜像中的所有文件到用户命名空间中映射的 UID 并创建一个新镜像。可以把它想象成一个 fedora:0:100000:5000 镜像。

当 Podman 在具有相同 UID 映射的镜像上运行另一个容器时，它使用“预先 chown”的镜像。当我在0:200000:5000 上运行第二个容器时，容器/存储会创建第二个镜像，我们称之为 fedora:0:200000:5000。

请注意，如果你正在执行 podman build 或 podman commit 并将新创建的镜像推送到容器注册库，Podman 将使用容器/存储来反转该移动，并将推送所有文件属主变回真实 UID=0 的镜像。

这可能会导致在新的 UID 映射中创建容器时出现真正的减速，因为 chown 可能会很慢，具体取决于镜像中的文件数。此外，在普通的 OverlayFS 上，镜像中的每个文件都会被复制。普通的 Fedora 镜像最多可能需要 30 秒才能完成 chown 并启动容器。

幸运的是，Red Hat 内核存储团队（主要是 Vivek Goyal 和 Miklos Szeredi）在内核 4.19 中为 OverlayFS 添加了一项新功能。该功能称为“仅复制元数据”。如果使用 metacopy=on 选项来挂载层叠文件系统，则在更改文件属性时，它不会复制较低层的内容；内核会创建新的 inode，其中包含引用指向较低级别数据的属性。如果内容发生变化，它仍会复制内容。如果你想试用它，可以在 Red Hat Enterprise Linux 8 Beta 中使用此功能。

这意味着容器 chown 可能在两秒钟内发生，并且你不会倍增每个容器的存储空间。

这使得像 Podman 这样的工具在不同的用户命名空间中运行容器是可行的，大大提高了系统的安全性。

前瞻

我想向 Podman 添加一个新选项，比如 --userns=auto，它会为你运行的每个容器自动选择一个唯一的用户命名空间。这类似于 SELinux 与单独的多类别安全（MCS）标签一起使用的方式。如果设置环境变量 PODMAN_USERNS=auto，则甚至不需要设置该选项。

Podman 最终允许用户在不同的用户名称空间中运行容器。像 Buildah 和 CRI-O 这样的工具也可以利用用户命名空间。但是，对于 CRI-O，Kubernetes 需要了解哪个用户命名空间将运行容器引擎，上游正在开发这个功能。

在我的下一篇文章中，我将解释如何在用户命名空间中将 Podman 作为非 root 用户运行。

【编辑推荐】

1. 如何在Linux中复制文档？
2. 记一次Linux木马清除过程
3. 最基本的Linux系统安全防护，你做到了吗？阿里云租用须看
4. 查找 Linux 发行版名称、版本和内核详细信息
5. Podman：一个更安全的运行容器的方式

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!