Docker 为什么不使用root用户作为默认用户

我已经阅读了关于Docker安全性的两个主题：

我知道Docker image是应用程序，root用户不安全，所以最好的选择是创建一个非root用户来运行我的服务

但是发展图像呢？当我需要构建应用程序而不是运行服务时使用的Docker映像

目前，我正在使用非root用户进行开发映像，但我发现使用它没有什么优势。例如，当我想在MSAzure中使用Docker映像作为容器作业运行时，它需要一个root用户。另外，当我需要更新我的映像时，比如安装一个新的包，我需要提升那个拥有sudo权限的用户

最后，当图像仅用于开发和构建时，Docker图像中是否有针对非root用户的真正建议

---

问候

dockers的优势之一是，您的开发环境完全模拟了prod中将发生的事情

让我给你一个我拥有的用例/bug

我们正在使用nginx作为我们的web服务器，我限制了根用户访问的prod-only映像，并且在开发过程中一切看起来都正常。发布后，我意识到nginx的请求缓冲区为16k，当它超过16k时，会将其写入磁盘（非root用户没有这样做的权限），并将错误500返回给客户端

---

在dev上一切看起来都正常，直到我在prod上收到的请求超过16K阈值

以下是对容器实际含义的杰出介绍：

容器是linux进程，运行在同一内核中，由名称空间分隔，并受cgroup限制

容器内的进程具有与其关联的用户ID（UID）和组ID（GID）：默认情况下，UID为0（等同于根）

如果容器内的进程能够与容器外的资源（如底层主机的文件系统）进行交互，那么它将使用与该进程的UID/GID相关联的访问权限进行交互。因此，在以uid0（root）运行的示例中，该进程可以访问和修改底层主机上的所有文件，这通常是一件坏事。（如果您使用的是SELinux，那么就没有这么简单了，但我们不要让事情复杂化）

因此，如果您可以保证您的容器进程不会触及底层主机的文件系统，并且它不会被外部系统劫持，那么您可能就没事了。但是，如果您的容器进程可能会被迫表现得异常，该怎么办？也许这是一个人为的例子，但也许它会接触到一个被篡改的外部服务，这会导致您的进程崩溃或改变其行为，从而写入底层主机的文件系统或生成一个侦听远程系统连接的进程

此外，您是唯一创建这些容器图像的人吗？很明显，你相信自己，但是如果其他人被允许建造类似的容器，你相信他们吗？比如说，真的，真的信任他们？你的集装箱可能很好，但他们的呢？您能保证它们不会（恶意或错误地）允许容器访问底层主机的文件系统或资源吗

---

最佳做法是容器永远不要使用UID 0运行。在某些情况下，这是绝对必要的，在企业环境中，以这种方式配置容器是一个巨大的危险信号，并且通常您的容器会被公司的安全系统阻止运行。如果必须将容器进程作为UID 0运行，那么考虑使用用户命名空间重新映射（描述和别处），这是容器在容器内运行具有UID 0的进程的一种方式（以便容器进程认为它是根），在容器外部，进程被赋予了非常不同的（非特权的）UID。当我说“开发图像”时，我的意思是，包含编译程序来构建应用程序的图像，它们不会运行配方，只是启动/构建/退出。容器不会通过卷接触我的磁盘，工件将被上传。您的用户案例是当容器运行服务（nginx）时，我完全同意以非root用户的身份运行该服务。我的情况比较孤立，我看不到什么问题，比如root用户构建应用程序时的用户读/运行/写权限。我想知道是否还有更多的实际问题，比如安全漏洞。谢谢你的评论，非常有趣。是的，可以保证我的容器不会触及我的文件系统，我不会使用--volume，-port，-z（selinux）。可能的缺陷是网络，我将使用“网桥”，它允许外部通信上传任何工件。该图像用于CI作业，但是公开的，在我的情况下没有问题，但可能用于正在使用的一些公司。我同意你的看法，UID 0并不酷，但在我的情况下，我需要，因为Azure容器作业需要UID 0来运行入口点。如果你对容器安全感兴趣，那么Jessie Frazelle（）对此很了解（值得在Twitter上关注）。再次感谢，我会关注她的。