生产环境中的无根模式 Podman：替代 Docker

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

简介

生产环境中的无根 Podman 已不再是一种技术猎奇，而是成为需要满足诸如 CIS 基准、PCI-DSS 和 LGPD 等合规性控制的环境中的实际要求。当我在服务器上运行 Docker 容器时，dockerd 需要一个特权套接字，而 docker 组中的任何用户实际上都拥有机器上的 root 权限。在内部审计中，我曾看到这一痛点导致整个部署流程受阻，而在过去两年中，我找到的最干净的解决方案是迁移到以无守护进程且无特权模式运行的 Podman。

本文的核心观点非常直接：在大多数 Web 和工作器场景中，无根 Podman 可以在不损失功能的前提下替代生产环境中的 Docker，前提是你接受三个明确的权衡——使用 systemd（通过 Quadlet）代替 docker compose，使用 subuid/subgid 映射用户 ID，以及在处理网络和卷时考虑到用户命名空间。作为回报，服务器变得可审计：没有任何容器进程以 host 主机上的 root 身份运行，远程代码执行（RCE）的攻击影响范围大幅缩小，且守护进程的攻击面完全消失。

我将展示如何从传统的 Docker 主机迁移到运行 .NET、n8n 和 Postgres 工作负载的 Podman 5.x 无根主机，并介绍经过三个月生产运营验证的目录结构、通过 SSH 进行的部署流水线，以及如果你不知道在哪里检查（端口 80、linger、网络“粘滞”问题、SELinux）可能会耗费数小时的陷阱。所有测试均在 Ubuntu 24.04 LTS 和 RHEL 9 上进行，默认运行时为 crun。

先决条件

• Linux，内核版本 ≥ 5.13（Ubuntu 22.04+、Debian 12+、RHEL 9+）
• Podman ≥ 4.4（以获得完整的 Quadlet 支持）；理想情况下为 5.x 版本
• 配置了 subuid/subgid 的非 root 用户
• 启用了用户模式的 systemd（loginctl enable-linger <用户>）
• 具备 Dockerfile 和 docker compose 的基础知识

为何无根模式并非“换个名字的 Docker”

我遇到的最常见误解是，仅仅因为 alias docker=podman 能够生效，就将 Podman 视为 Docker 的直接替代品。虽然这对 run、build 和 pull 命令有效，但其执行模型截然不同。

Docker 依赖于一个以 root 身份运行并在 /var/run/docker.sock 上监听的守护进程（dockerd）。正是这个守护进程负责执行容器。如果攻击者能够对该套接字进行任何写入操作，他就能通过挂载主机的根目录 / 获得一个 --privileged（特权）容器——游戏结束。这就是为什么 CIS Docker 基准测试 1.2.x 版本专门用整整一个章节来讨论该套接字的安全问题。

Podman 是无守护进程的。每个 podman run 都是你的 shell（或 systemd --user）的子进程。默认情况下不存在特权套接字。在无根模式下，容器运行在通过 subuid/subgid 映射的用户命名空间中：容器内的 UID 0 实际上是主机上一个高数值且无特权的 UID（例如：100000）。如果进程逃逸出容器，它将以一个普通用户的身份落地，几乎对任何内容都没有写入权限。

ℹ️ 信息：在红帽公司针对 CVE-2019-5736（经典的 runc 逃逸漏洞）的测试中，Docker 有根模式下的利用程序能够覆盖主机上的 runc 二进制文件。而在无根 Podman 中，同样的利用程序将以 UID 100000 的身份落地，且没有写入权限——容器虽然“逃逸”了，但不会造成损害。

这种差异