Question

我正在尝试找到有关以下方面的通用最佳实践：

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

我已经搜索并尝试了几天，但仍无法提出令人满意的解决方案。

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

FROM mariadb:10.3

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

USER 1234

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

我了解that the VOLUME directive works that way by design以及why it's like that，但对我来说，这似乎完全阻止了针对给定问题的简单解决方案：采用Dockerfile并以简单，干净且简约的方式对其进行调整，以非root用户而不是root用户身份运行。

背景是：我正在尝试在Openshift集群上运行任意Docker映像。 Openshift by default prevents running containers as root，我想保持这种状态，因为它看起来非常理智，并且在安全方面朝正确的方向迈出了一步。

这意味着像gosu这样的解决方案在此还不够好，该解决方案期望容器以root用户身份启动以在运行时删除特权。我想采用一种方法，该方法根本不需要以根用户身份启动容器，而仅以指定的USER或什至具有随机UID的身份启动容器。

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

复制 parent Dockerfile并以必要的方式进行调整（有效地复制代码）
sed / awk在构建期间遍历所有服务的配置文件，以将原始VOLUME路径替换为备用路径，因此chgrp和{{1} }可以正常工作（保留原来的chmod路径为孤立路径）。

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

所以必须有更好的方法来做到这一点，对吗？我想念的是什么？非常感谢您的帮助。

Answer 1

对卷挂载点的权限完全无关紧要，该挂载掩盖了任何从那里开始的潜在权限。此外，您可以在Kubernetes级别上设置此类内容，而不必担心Dockerfile。通常这通常是PodSecurityPolicy，但您也可以在Pod本身的SecurityContext中进行设置。

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

1 个答案: