我正在尝试从以非 root 用户身份运行 OpenLDAP 服务的无 root Podman 容器访问共享证书密钥。该密钥具有组读取权限,并且运行我的容器的用户是该组的成员。我不想复制 TLS 密钥,因为这样,如果密钥发生变化,就必须再次复制密钥,这会给流程带来额外的复杂性和风险。
细节:
我正在运行无根 Podman 容器,用户 ID 为 4610,该用户是 certs 组 (ID 1012) 和组 4610 的成员。在容器内运行服务的用户也不是 root(容器内的用户 ID 也是 4610)。我试图将证书密钥挂载到具有所有权 root:certs 和权限 rw-r----- 的主机上,以便容器内的用户 4610 可以访问它。显然,在主机上,用户可以访问该文件,因为他是 certs 组的成员,并且该文件具有组读取权限。
我的 /etc/subuid 和 /etc/subgid 都有这一行:
4610:100000:65536
如果我的 docker-compose 文件包含以下行,则允许容器访问主机上所有者为 4610 的文件:
userns_mode: "keep-id"
user: "4610"
这会将主机 UID 4610 映射到容器,这样,如果我在主机上有所有者为 4610 的文件,则容器内的所有者也会被视为 4610。但是,在容器内,主机上所有者为 root:certs 的密钥文件被视为由 nobody:nogroup (ID 65534:65534) 拥有。
如何实现挂载,以便容器内的用户 4610 可以访问密钥文件?
在 Erik Sjölund 的提示的帮助下,我终于解决了这个问题。
第一个解决方案是仅使用
podman run
,并添加--group_add keep-groups
选项。如果您正在使用撰写文件,解决方案是将其添加到撰写文件中:
Keep-groups“保留”启动容器的用户的组,即神奇地允许容器读取具有组读取权限的文件。
如果您使用 podman-compose,第二个选项是添加一个文件
~/.config/containers/containers.conf
:当然,这会影响所有用户的容器。~ 文件夹自然是运行容器的用户的家。
有趣的是,当我进入容器时,文件的所有者或权限没有改变。该文件似乎仍然归nobody:nogroup 所有,并且具有权限:
rw-r-----
。用户尚未添加到此“nogroup”组。但cat {path to key file}
仍然打印了文件,并且服务也能够读取它。我猜想还需要一些额外的技巧来映射容器内的组并使服务用户成为该组的成员。我尝试的最后一个解决方案是创建一个(用户)cron 作业,例如每 5 分钟检查一次证书文件是否已更改,如果已更改,则将证书文件复制到 podman 用户的目录中,赋予它们 podman 用户的所有权和用户读取它们的权限,然后重新启动容器。复制的文件已挂载到容器中。