守护进程安全该不该用：先看它解决的问题是不是你的问题

能访问 docker.sock 就等于能在宿主上以 root 执行命令，docker 组本质是 root 组

它擅长的是多租户构建机；如果你只是暴露端口的服务，用现成的东西更省事。

先说结论

容器安全的第一条不是扫镜像，是「别把 root 的开关交出去」

• 适合：多租户构建机
• 不适合：CI runner 隔离
• 学习成本：开启 userns-remap 后容器内 root 映射到宿主 100000 起始的 UID，逃逸收益大减
• 最大收益：默认容器带 14 项左右 capabilities，多数应用只需要其中 2-3 项
• 最大风险：为图方便把 docker.sock 挂进容器，任何 RCE 都变成宿主 root

它到底解决什么

能访问 docker.sock 就等于能在宿主上以 root 执行命令，docker 组本质是 root 组。

换句话说，它把「多租户构建机」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

为图方便把 docker.sock 挂进容器，任何 RCE 都变成宿主 root

用 --privileged 解决权限问题，等于关掉所有隔离

把用户加进 docker 组当普通权限，实际给的是 root

和替代方案比

--read-only 会让应用写临时文件失败，需要显式挂一个 tmpfs。

这台工具的关键细节

几个决定长期体验的点：

• 开启 userns-remap 后容器内 root 映射到宿主 100000 起始的 UID，逃逸收益大减
• 默认容器带 14 项左右 capabilities，多数应用只需要其中 2-3 项
• --read-only 会让应用写临时文件失败，需要显式挂一个 tmpfs
• seccomp 的默认配置已禁用 40 多个系统调用，改成 unconfined 等于全放开

我的建议

容器安全的第一条不是扫镜像，是「别把 root 的开关交出去」。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

工具是解法，不是身份。