从现有的 Dockerfile 派生 + 将 USER 设置为非 root

Question

我正在尝试找到一个通用的最佳实践来：

1. 采用任意（父）Dockerfile，例如，以 root 身份运行其容器化服务的官方 Docker 映像之一，
2. 从中派生一个自定义（子）Dockerfile（通过FROM... ），
3. 调整child使其运行与parent相同的服务，但作为非 root 用户。

我已经搜索和尝试了好几天，但一直未能找到令人满意的解决方案。

我想提出一种方法，例如类似于以下内容，只是为了调整用户，原始服务运行为：

FROM mariadb:10.3

RUN chgrp -R 0 /var/lib/mysql && \
    chmod g=u /var/lib/mysql

USER 1234

但是，我一次又一次遇到的问题是，每当父Dockerfile 将某些路径声明为VOLUME （在上面的示例中实际上是VOLUME /var/lib/mysql ）时，这实际上使子Dockerfile 无法调整文件权限对于该特定路径。 在这种情况下chgrp和chmod无效，因此由于文件访问权限问题，生成的 docker 容器将无法成功启动。

我知道VOLUME指令是按设计方式工作的，以及为什么会这样，但对我来说，它似乎完全阻止了给定问题的简单解决方案：采用 Dockerfile 并以简单、干净和简约的方式对其进行调整以非 root 而不是 root 身份运行。

背景是：我正在尝试在 Openshift 集群上运行任意 Docker 图像。 默认情况下，Openshift 会阻止以 root 身份运行容器，我想保持这种方式，因为它看起来很理智，并且朝着正确的方向迈出了一步，安全方面。

这意味着像gosu这样的解决方案，期望容器以 root 身份启动以便在运行时放弃特权，在这里还不够好。 我想要一种方法，它根本不需要容器以 root 身份启动，而只需要以指定的USER甚至随机 UID 身份启动。

到目前为止，我发现的不满意的方法是：

• 复制父Dockerfile 并以必要的方式调整（有效复制代码）
• sed / awk在构建期间通过所有服务的配置文件将原始VOLUME路径替换为备用路径，因此chgrp和chmod可以工作（使原始VOLUME路径成为孤立的）。

我真的不喜欢这些方法，因为它们需要真正深入了解父Dockerfile 的逻辑和基础架构以及服务本身的运行方式。

所以必须有更好的方法来做到这一点，对吧？ 我错过了什么？ 非常感谢您的帮助。

Answer 1

卷挂载点的权限根本不重要，挂载覆盖了任何底层权限。 此外，您可以在 Kubernetes 级别设置这种东西，而不用担心 Dockerfile。 这通常是一个 PodSecurityPolicy，但您也可以在 Pod 本身的 SecurityContext 中设置它。