仅访问本地文件生成PDF时，如何安全运行Puppeteer Docker镜像？

背景说明 #

Puppeteer官方Docker镜像的运行指引提到：

运行命令示例：puppeteer-chrome puppeteer-chrome-linux node -e "cat test.js"
--cap-add=SYS_ADMIN 权限是启用Chromium沙箱（提升浏览器安全性）所必需的。或者，也可以通过--no-sandbox标志启动浏览器二进制文件。

但需明确：给Docker容器授予SYS_ADMIN权限本质上等同于赋予对宿主机的root权限，风险极高。

1. 是否存在无需添加--cap-add=SYS_ADMIN即可安全运行该镜像的方法？ #

有多种替代方案可避免授予SYS_ADMIN权限，同时保留Chromium沙箱的安全特性：

• 启用Docker User Namespace映射：在宿主机开启User Namespace配置，将容器内的root用户映射为宿主机的普通用户。即便容器内拥有SYS_ADMIN权限，在宿主机层面也会被限制为普通用户权限，大幅降低风险。
• 使用自定义Seccomp Profile：为容器配置仅允许Chromium沙箱所需系统调用的Seccomp规则，而非直接授予全量SYS_ADMIN权限。Puppeteer官方提供适配的Seccomp配置模板，可实现最小权限原则。
• 以非root用户运行容器：修改镜像或启动命令，用普通用户身份启动Node进程和Chromium。多数新版Puppeteer镜像已默认采用非root用户运行，配合--disable-setuid-sandbox参数，即可在无需SYS_ADMIN的情况下启用沙箱，仅需确保容器内用户拥有必要的文件读写权限。
• 添加--disable-setuid-sandbox启动参数：启动Chromium时加入该参数，可绕过对SYS_ADMIN权限的依赖，同时保留沙箱核心安全防护能力，适合非root用户运行的场景。

2. 若确保仅向Chrome传递本地生成的文件，禁用沙箱是否安全？ #

如果能严格满足以下条件，禁用沙箱的风险处于可控范围：

• 本地生成的文件完全由你掌控，不包含任何恶意代码或逻辑；
• 文件不会加载任何外部资源（如远程JS、CSS、图片等），完全处于离线隔离状态。

但必须明确：禁用沙箱意味着Chromium失去最核心的安全隔离层，一旦文件中存在未被发现的漏洞或恶意代码（哪怕是误引入的），攻击者可直接获取容器内权限，进而威胁宿主机。因此即使是本地文件，也建议优先采用上述保留沙箱的替代方案，而非直接禁用沙箱。

内容的提问来源于stack exchange，提问作者Paul Verest on LinkedIn