我已经阅读了有关Docker安全性的两个主题：
https://docs.docker.com/engine/security/security/
https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b
对于Docker映像（我是应用程序），我知道root用户并不安全，因此最好的选择是创建一个非root用户来运行我的服务。
但是开发映像呢？在我需要构建应用程序而不是运行服务时使用的Docker映像？
当前，我正在使用非root用户来开发映像，但是使用它时我看不到任何好处。例如，当我想在MS Azure中使用Docker映像作为容器作业运行时，它需要一个root用户。另外，当我需要更新映像时（例如安装新软件包），我需要提升具有sudo权限的用户。
最后，当镜像仅用于开发和构建时，对于Docker镜像中的非root用户是否有真正的建议？
致谢！
答案 0 :(得分：1)
以下是有关容器实际内容的出色介绍：https://www.slideshare.net/jpetazzo/anatomy-of-a-container-namespaces-cgroups-some-filesystem-magic-linuxcon
容器是linux进程，在同一内核中运行，由命名空间分隔并受cgroups限制。
容器中的进程具有用户ID（UID）和与之关联的组ID（GID）：默认情况下，UID为0（等于root）。
如果容器内的进程能够与容器外的资源（例如基础主机的文件系统）进行交互，则它将使用与该进程的UID / GID相关联的访问权限来进行此操作。因此，在以UID 0（根）运行的示例中，该进程可以访问和修改基础主机上的所有文件，这通常是一件坏事。 （如果您使用的是SELinux，那不是那么简单，但是我们不要让事情复杂化。）
因此，如果您可以保证容器进程不会碰到基础主机的文件系统，并且不能被外部系统劫持，那么您可能。但是，如果您的容器过程可以被强制执行为异常行为该怎么办？也许这是一个虚构的示例，但也许它涉及到已被篡改的外部服务，这会导致您的进程崩溃或更改其行为，从而使该进程写入底层主机的文件系统或生成一个侦听连接的进程从远程系统？
此外，您是唯一创建这些容器图像的人吗？显然，您信任自己，但是如果允许其他人构建类似的容器，您是否信任它们？作为，真的，真的相信他们吗？您的容器可能没问题，但是容器呢？您能保证他们不会（恶意或错误地）允许他们的容器访问底层主机的文件系统或资源吗？
最佳实践是使容器永远不要以UID 0运行。在少数情况下，这是绝对必要的，在企业环境中，以这种方式配置容器是一个巨大的危险信号，并且通常情况下，容器将被公司的安全系统阻止运行。如果必须以UID 0运行容器进程，请考虑使用用户名称空间重映射（在here和here等地方进行介绍），这是容器在容器内部运行UID 0的进程的一种方式（以便容器进程认为它是根），在容器外部，为该进程提供了一个非常不同的（非特权）UID。
答案 1 :(得分：0)
泊坞窗的优势之一是您的开发环境完全模拟了产品中将发生的事情
让我给您一个用例/错误
我们正在使用nginx作为我们的Web服务器，我只限制了用于根访问的prod图片，并且在开发过程中一切正常。发布后，我意识到nginx具有16k的请求缓冲区，当它超过该缓冲区时，会将其写入磁盘（非root用户没有权限这样做），并将错误500返回给客户端。
对于开发人员，一切看起来都不错，直到我收到的产品请求大于16K阈值为止。