以非根用户身份运行的docker容器进程无法写入docker卷 太长,读不下去了 每个人都建议容器中的进程永远不要作为根运行 (除了kubernetes)似乎没有一个好的devops/configuration-as-code方法在docker卷上设置正确的所有者/权限,因此(非root)用户无法写入卷

以非根用户身份运行的docker容器进程无法写入docker卷 太长,读不下去了 每个人都建议容器中的进程永远不要作为根运行 (除了kubernetes)似乎没有一个好的devops/configuration-as-code方法在docker卷上设置正确的所有者/权限,因此(非root)用户无法写入卷,docker,docker-compose,file-permissions,docker-swarm,cloud-storage,Docker,Docker Compose,File Permissions,Docker Swarm,Cloud Storage,那么,当以非root用户身份运行容器进程并且我想写入(cloudstor、aws ebs)docker卷时,什么是好的实践呢 长话短说 在(和外部)docker容器中,以root用户身份运行进程被认为是一种不好的做法(例如,请参见…)。这可能会涉及安全问题 但当我们开始使用docker卷,而非root用户试图写入该卷时,问题就开始了。我没有找到一个干净的解决方案,可以在云基础设施上工作,而不需要人工干预。我找到的工作解决方案似乎都在某些方面(安全性、可维护性等)存在不足 作为补充说明,我们正在

那么,当以
非root
用户身份运行容器进程并且我想写入(cloudstor、aws ebs)docker卷时,什么是好的实践呢


长话短说 在(和外部)docker容器中,以root用户身份运行进程被认为是一种不好的做法(例如,请参见…)。这可能会涉及安全问题

但当我们开始使用docker卷,而非root用户试图写入该卷时,问题就开始了。我没有找到一个干净的解决方案,可以在云基础设施上工作,而不需要人工干预。我找到的工作解决方案似乎都在某些方面(安全性、可维护性等)存在不足

作为补充说明,我们正在使用
cloudstor
docker swarm
上部署
aws ebs
卷。我们希望有一天搬到kubernetes,但我们还没有kubernetes,所以我们尝试为我们的设置找到一个替代解决方案

考虑的解决方案/变通办法 1.在docker映像中预创建卷 按照建议,如果
docker compose
创建了一个新的卷,则会传播映像内目录的权限

缺点:

  • 如果卷以前存在,或者它是磁盘上的文件夹,则此操作将不起作用
  • 如果使用
    cloudstor
    配置卷,这可能也不起作用,因为它不会
    docker compose
    配置卷(未测试)
2.使用卷供应器 hasnat创建了一个映像,可以在真正的容器启动之前设置正确的文件夹权限

缺点:

  • 需要在docker堆栈中添加额外的服务。此服务几乎立即停止(在设置权限后)
  • 真正的容器需要依赖于卷供应器。重新部署同一堆栈时(配置更改后),执行顺序不受保证
  • ebs
    卷只能装载在单个docker容器上,这会导致许多部署问题
3.使用
docker run
更正文件权限 一旦真正的容器在装载卷的情况下运行(但仍然具有错误的权限),我们调用

缺点:

  • ebs
    卷只能装入一个容器中,因此这将产生冲突
  • 此命令只能在部署docker堆栈后运行(否则卷尚未配置),因此在真正的容器启动和正确的权限之间会有延迟。这意味着在启动时,真正的容器会找到具有错误权限的卷,因此只有在服务不断检查权限是否已更正的情况下,此操作才会起作用
4.启动容器时更改所有权 这意味着:

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

  • 当容器进程以root用户身份运行时,仍然有一个(较小的?)时间段(安全隐患?)
  • 需要破解入口点,覆盖用户,。。。为了让这项工作正常进行,需要官方图片
5.以root用户身份运行 这是最简单的解决方案,但是安全性呢?每个人都建议不要这样做

6.使用kubernetes 正如所建议的,使用kubernetes,我们可以将组id分配给卷。这一点似乎在美国得到了证实

缺点:

  • (遗憾的是)我们还没有使用
    kubernetes
  • (未经测试。)
7.在具有正确权限的文件系统上创建文件夹 确保文件系统上存在具有正确所有者/权限的目录

缺点

  • 这不是云存储。。。如果容器切换到另一个节点怎么办?或者如果服务器崩溃?(这就是为什么我们使用
    cloudstor
    ,它甚至允许我们切换可用性区域)
  • 似乎不太“配置为代码”

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

在k8s中以root用户身份运行服务是非常困难的。对于
docker compose
环境,我们在不启动服务的情况下创建所有内容(
docker compose-no start
),然后设置权限(
docker run--rm-it--volumes from…--entrypoint chown alpine:3-R 1000:1000/data
),然后启动服务。对于k8s,afaik正在使用的常见做法。您不能将docker用户添加到有权访问卷的用户组吗?@clogwog在容器内运行进程的用户对于每个容器都不同,并且与docker用户不同
docker run --rm -u root -v ${MOUNT}:${TARGET} { real_image } chown -R user:group ${TARGET}