看起来最好的选择是使用自定义 seccomp 配置文件

你可以在这里看到一个例子

您需要的文件的其他链接以防它们消失：

wget https://raw.githubusercontent.com/jfrazelle/dotfiles/master/etc/docker/seccomp/chrome.json

wget https://raw.githubusercontent.com/Zenika/alpine-chrome/master/chrome.json

示例用法：

docker container run -it --rm --security-opt seccomp=$(pwd)/chrome.json zenika/alpine-chrome

我认为以非 root 用户身份运行 puppeteer 不需要对底层主机的配置进行任何修改，因为有许多 Docker 镜像可以成功地做到这一点。

一个例子是基于 Puppeteer 构建的Decktape。Docker 映像（在 GH 存储库中链接了命令）以用户身份运行node并在未修改的 Linux 实例上运行。

我有同样的问题，并在 stackexchange 上遇到了同样可怕的答案/评论。在阅读了另一个答案中链接的lwn.net 文章，并阅读了 stackexchange 上所有明显相关的答案后，我想我已经理解了这个问题。

问题似乎在于创建隔离环境涉及克隆“用户名称空间”。使用默认设置，unprivileged_userns_clone=0您可以克隆一次命名空间，但是，一旦进入命名空间，就无法再次进一步克隆命名空间。由于 docker 和 chrome 都创建了一个沙盒命名空间，因此不可能从 docker 容器内部运行 chrome 而无需跳过额外的环节。请注意，运行打包为 AppImage 的电子应用程序时会出现同样的问题。

因此，要回答这里提出的具体问题：不，我认为这并不等于将您的服务器开放给一半的互联网，尽管设置unprivileged_userns_clone=1不是最安全的选择。

似乎有三种方法可以解决这个问题：

1. 使用 --no-sandbox 运行 chrome（或电子）。这可能没问题，因为 docker 已经提供了一定程度的隔离。
2. 按照另一个答案的建议设置自定义 seccomp 配置文件。
3. 覆盖kernel.unprivileged_userns_clone内核中的默认设置以允许嵌套命名空间克隆。这是据称危险的活动。似乎禁用 unprivileged_userns_clone 是一种强化措施，它可以防止在某种程度上可能并且可能确实存在的一类未知但潜在的漏洞。因此，这可能不是一个绝对明显的安全风险。它在一定程度上削弱了安全性，但似乎不会让您面临直接且已知的“野外”安全威胁。

简短版本：我同意这个答案，但我无法投票赞成这个答案，因为我还没有足够的声誉。