以非root用户身份运行的docker容器进程无法写入docker卷 1在docker映像中预创建卷 2使用volume-provisioner 3使用docker run来更正文件权限 4启动容器时更改所有权 5只需以root身份运行 6使用kubernetes 7在文件系统上创建具有正确权限的文件夹

如何解决以非root用户身份运行的docker容器进程无法写入docker卷 1在docker映像中预创建卷 2使用volume-provisioner 3使用docker run来更正文件权限 4启动容器时更改所有权 5只需以root身份运行 6使用kubernetes 7在文件系统上创建具有正确权限的文件夹

TLDR

• 每个人都建议容器内的进程永远不要以root身份运行
• （kubernetes除外）似乎没有一种好的devops / codes配置方式来获取对Docker卷设置的正确所有者/权限，因此（非root用户）不能写卷

当以non-root用户身份运行容器进程并且我想写入docker卷（cloudstor，aws-ebs）时，什么是良好实践？

---

长话

在Docker容器中（外部）以root用户身份运行进程被认为是不好的做法（例如，参见ref1，ref2，...）。这可能会带来安全隐患。

但是，当我们开始使用docker卷并且该非root用户尝试写入该卷时，麻烦就开始了。我没有找到一种无需人工干预即可在云基础架构上运行的干净解决方案。我发现所有可行的解决方案在某些方面（安全性，可维护性...）都不够。

作为一个附带说明，我们正在docker-swarm上使用cloudstor部署aws-ebs卷。我们希望有一天能迁移到kubernetes，但我们还没有kubernetes，因此我们尝试为我们的设置找到替代解决方案。

考虑的解决方案/解决方法

1。在docker映像中预创建卷

按照here的建议，如果docker-compose创建一个 new 卷，则将传播图像内目录的权限。

缺点：

• 如果该卷以前存在，或者它是磁盘上的文件夹，则此功能将不起作用
• 如果用cloudstor设置了卷，则可能也不起作用，因为不会docker-compose设置了卷（未测试）

2。使用volume-provisioner

hasnat创建了一个volumes-provisioner图像，可以在实际容器启动之前设置正确的文件夹权限。

缺点：

• 需要在Docker堆栈中添加额外的服务。该服务几乎立即消失（在设置权限之后）。
• 真实的容器需要 depends_on volumes_provisioner。重新部署同一堆栈（配置更改后）时，不能保证执行顺序
• ebs卷只能安装在单个docker容器上，这会导致许多部署问题

3。使用docker run来更正文件权限

一旦真实容器在安装了卷的情况下运行（但权限仍然错误），我们将调用

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

缺点：

• ebs卷只能安装在一个容器中，因此会产生冲突
• 此命令只能在部署docker-stack之后运行（否则尚未配置卷），因此在实际容器启动和正确权限之间会有延迟。这意味着在启动时，真实的容器会找到具有错误权限的卷，因此只有在服务不断检查权限是否已得到纠正的情况下，这才起作用。

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

这意味着：

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

缺点：

• 容器进程以root身份运行时（仍然存在一个（较小的？）时间段（安全隐患？）
• 需要破解入口点，覆盖用户等正式图片才能正常工作

5。只需以root身份运行

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

6。使用kubernetes

如建议here所示，使用kubernetes，我们可以为卷分配组ID。 kubernetes documentation for pods似乎证实了这一点。

缺点：

• （不幸的是）我们还没有使用kubernetes。
• （未经测试。）

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

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

缺点

• 这不是云存储...如果容器切换到另一个节点怎么办？还是服务器崩溃？ （这就是我们使用cloudstor的原因，它甚至允许我们切换可用性区域）
• 似乎不是很“按代码配置”

解决方法

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