告别 Root 风险：Podman 无根容器安全实践全解析

52JinY 助手

聊聊 Podman 和 rootless 容器这件事，说实话我一开始是被逼着用的。

我们组里有个老运维，Docker 用了七八年，死活不肯动。直到有一次生产环境上一个容器进程跑崩了，顺带把宿主机的 /etc/passwd 给改了——是的，你没看错——那次之后所有人都沉默了。事故复盘会上有人提到 Podman，大家才开始认真研究这个方向。

Podman 最核心的改变其实就一条：守护进程不以 root 身份运行，甚至默认就没有守护进程。传统 Docker 架构里，dockerd 是 root 权限的常驻服务，你只要能 socket 通信，基本上就等于拿到了 root。这个设计在便利性上无可挑剔，但安全边界完全依赖你自己的权限管控，稍有疏漏就是灾难。Podman 的 rootless 模式则是让普通用户在自己的用户命名空间里跑容器，进程在宿主机视角下就是个普通用户，即便容器内是 root，出来之后也就是映射后的 UID，造成的破坏面极其有限。

当然，rootless 不是没有代价的。刚迁移那段时间，我们踩了不少坑。最典型的是网络问题——rootless 容器默认无法绑定低于 1024 的端口，不能直接用 iptables，网络性能也因为走 slirp4netns 用户态协议栈而有所下降。还有存储驱动，rootless 环境下 overlay 的支持依赖内核版本，老机器上可能得退回 fuse-overlayfs，速度差一截。这些都是真实存在的权衡，不能假装没有。

我觉得安全实践里有几个点特别值得强调。第一是不要把 rootless 当成万能挡箭牌，它降低的是提权到宿主机 root 的风险，但容器内部的隔离还是靠 seccomp、capabilities 和 SELinux/AppArmor 来保障。Podman 默认会应用一套 seccomp profile，建议在此基础上根据业务做裁剪，把不用的系统调用全部 drop 掉。第二是镜像来源的管控，这和用不用 Podman 关系不大，但经常被忽视。rootless 容器跑一个恶意镜像，一样能在用户空间里搞破坏。我们内部要求所有镜像必须经过私有 registry 的扫描和签名验证，这一块用 cosign 配合 policy.json 做的，效果还不错。第三点是关于 pod 和 systemd 集成——Podman 和 systemd 配合得相当好，可以用 podman generate systemd 生成服务文件，让容器跟随用户会话自启，这在没有 Kubernetes 的小规模部署里非常实用，管理成本大幅下降。

还有一个容易被忽略的地方：用户命名空间的 UID 映射范围。默认情况下 /etc/subuid 和 /etc/subgid 会给每个用户分配 65536 个 UID，这个范围够用，但如果你的镜像里有进程需要特定 UID，记得提前确认映射关系，否则文件权限会出现一些奇怪的问题，排查起来很费时间。

总体来说，Podman 加上 rootless 这条路走下来，整体安全姿态确实比之前强了不少，但它不是开箱即用的零配置安全方案。你还是需要理解背后的机制，根据自己的场景做调整。那些期待"换个工具就安全了"的想法，在这个领域从来都不成立。工具只是护栏，真正的安全意识才是底座。