使用Sysbox运行时的Docker Swarm能否指定Secret的UID？

你的推测是对的：Sysbox的用户ID映射机制会导致Docker Swarm原生的Secret挂载UID/GID配置失效，最终Secret会以nobody用户挂载。这是因为Swarm在主机侧处理Secret的权限设置，但Sysbox容器通过用户命名空间隔离，容器内的UID/GID和主机侧是映射关系，而非直接对应。

要在Sysbox环境下实现指定Secret的UID/GID和权限，有两种可行方案：

方案1：调整Sysbox的ID映射规则，对齐容器与主机的UID #

通过自定义Sysbox配置，让容器内的目标UID直接映射到主机的对应UID，这样Swarm设置的权限就能直接生效：

1. 创建或编辑Sysbox配置文件/etc/sysbox/sysbox.conf，添加如下映射规则（以UID/GID 1234为例）：

   userns.uid_map = "1234:1234:1"
   userns.gid_map = "1234:1234:1"
   

   这条规则表示容器内的UID 1234直接对应主机的UID 1234，映射范围为1个ID。
2. 重启Sysbox服务使配置生效：

   systemctl restart sysbox
   

3. 重新部署你的Swarm服务，此时Secret会以指定的UID/GID挂载到容器内。

注意：这种方式会降低容器的隔离性，因为容器内的特定UID直接关联到主机的真实用户，仅在信任的环境中使用。

方案2：在容器内手动调整Secret权限（推荐） #

Sysbox作为系统容器，允许容器内执行特权操作，因此可以在容器启动阶段手动修改Secret的权限，避开主机侧ID映射的影响：
修改Swarm服务配置，在command或entrypoint中添加权限调整命令，示例如下：

services:
  service1:
    image: your-image:tag
    runtime: sysbox-runc
    secrets:
      - source: secretname
    command: >
      bash -c "chown 1234:1234 /run/secrets/secretname && chmod 0600 /run/secrets/secretname && your-original-command"

容器启动后会先调整Secret的所有者和权限，再执行原业务命令，确保Secret以预期权限被访问。

内容的提问来源于stack exchange，提问作者Coert Metz