作为非root用户运行的docker容器进程不能写入docker卷。

Question

TLDR

• 每个人都建议容器中的进程永远不要以root的形式运行。
• (除了kubernetes)似乎没有一种很好的devop/configuration-as-code方法来获得对坞库卷的正确所有者/权限设置，因此(非根用户)不能写入卷。

然后，当以non-root用户的身份运行容器进程时，什么是好做法?我想要写入(cloudstor，aws)停靠卷。

长话短说

在(和外部)坞容器中以根用户身份运行进程被认为是错误的做法(例如，请参见ref1、ref2、.)。这可能会对安全产生影响。

但是，当我们开始使用docker卷，而非根用户试图写入卷时，问题就开始了。我找不到一个干净的解决方案，可以在没有人工干预的情况下，在云基础设施上工作。我发现的工作解决方案在某些方面似乎都不完善(安全性、可维护性、.)。

顺便提一下，我们正在docker-swarm上部署，使用cloudstor提供aws-ebs卷。我们希望有一天能搬到kubernetes，但是我们还没有kubernetes，所以我们试图为我们的设置找到一个替代的解决方案。

考虑的解决办法/解决办法

1.预先创建码头映像中的卷。

如建议的这里一样，如果docker-compose创建了一个新的卷，则图像中目录的权限将被传播。

缺点：

• 如果以前存在卷，或者它是磁盘上的文件夹，则此操作将无法工作。
• 如果卷是用cloudstor提供的，这可能也不起作用，因为它不会是docker-compose配置卷(没有测试)

2.使用卷-供应器

hasnat创建了一个卷-供应器映像，它可以在真正的容器启动之前设置正确的文件夹权限。

缺点：

• 需要在码头堆栈中添加额外的服务。此服务几乎立即死亡(在设置权限之后)。
• 真正的容器需要depends_on volumes_provisioner。当重新部署相同的堆栈时(在配置更改后)，执行顺序得不到保证。
• ebs卷只能安装在单个坞容器上，这导致了许多部署问题。

3.使用docker run更正文件权限

一旦真正的容器在安装了卷的情况下运行(但仍然具有错误的权限)，我们将调用

docker run --rm -u root -v ${MOUNT}:${TARGET} { real_image } chown -R user:group ${TARGET}

缺点：

• ebs卷只能在一个容器中挂载，因此会产生冲突。
• 此命令只能在部署了docker-堆栈之后才能运行(否则尚未提供卷)，因此在真正的容器启动和正确的权限之间会出现延迟。这意味着，在启动时，真正的容器会找到具有错误权限的卷，所以只有当服务不断检查权限是否已被更正时，才会有效。

4.启动容器时更改所有权

这意味着：

• 以root用户身份启动进程(否则我们无权更改目录所有者/权限)
• 更改所有权/权限
• 切换到non-root用户

缺点：

• 还有一个(小调？)容器进程作为根进程运行的时间段(安全含义？)
• 需要破解入口点覆盖用户..。为了让这件事起作用

5.以根的形式运行

这是最简单的解决方案，但是安全又如何呢？每个人都建议而不是来做这个？

6.使用kubernetes

正如建议的这里，对于kubernetes，我们可以为卷分配一个组id。库伯奈特豆荚文件似乎证实了这一点。

缺点：

• (遗憾的是)我们还没有使用kubernetes。
• (未经测试)

7.在文件系统上创建具有正确权限的文件夹

确保文件系统中存在具有正确所有者/权限的目录。

不利

• 这不是云存储..。如果容器切换到另一个节点怎么办？或者如果服务器崩溃？(这就是我们使用cloudstor的原因，它允许我们切换可用性区域)
• 看起来不太“配置为代码”

Answer 1

我投票赞成解决方案4，没有安全问题要将权限更改为root，然后以非root身份启动应用程序。如果您的应用程序中存在安全漏洞，那么无论在启动之前发生了什么，应用程序仍然没有以根用户的身份运行。您可以在入口点中的脚本中使用此操作。