k8s文件挂载权限分析

本文章主要针对以下两种场景进行分析

• 本地挂载
• NFS挂载

---

本地挂载

结论：挂载的文件的用户权限，在容器内部看到的uid、gid及操作权限，与宿主机上看到的一致
宿主机新建挂载目录：

宿主机查看权限

拉起docker镜像，并把宿主机目录挂载到容器中
docker run -d --rm --name busybox -v /root/test:/tmp/ busybox sleep infinity

查看容器内文件目录权限

一定要确保容器执行者的权限和挂载数据卷对应，如果挂载了root的文件到容器内部，而容器内部执行uid不是0，则报错没有权限

---

NFS挂载

服务端：

NFS服务端共享文件权限

owner的uid及gid

容器内：

NFS挂载到tmp

结论：挂载的文件的用户权限，在容器内部看到的uid、gid及操作权限，与NFS服务端上看到的一致。

但是容器中的用户身份对于NFS服务端来说，需要根据NFS的配置文件进行判断：

• root_squash：默认选项，当客户端使用的是root用户时，则映射到NFS服务器的用户为NFS的匿名用户（nfsnobody）。
• no_root_squash：当客户端使用的是root用户时，则映射到FNS服务器的用户依然为root用户。
• all_squash：默认选项，将所有访问NFS服务器的客户端的用户都映射为匿名用户，不管客户端使用的是什么用户。
• no_all_squash：当客户端使用的用户的uid和gid在服务器端中也存在一致uid和gid的用户时，则映射到NFS服务器的用户为对应用户，其他用户则映射为匿名用户
• anonuid：设置映射到本地的匿名用户的UID
• anongid：设置映射到本地的匿名用户的GID

举例：

假设服务器端共享文件夹的访问权限

服务端NFS配置：

1. no_root_squash,no_all_squash

存在以下几种情况：

• 客户端当前用户为root（uid=0，gid=0），正常读写；
• 客户端当前用户为test（uid=1001，gid=1001），映射成服务端的test，正常读写；
• 客户端当前用户为user1（uid=1001，gid=1001），映射成服务端的test，正常读写；
• 客户端当前用户为rancher（uid=1000，gid=1000），映射成服务端的rancher，只能读不能写；
• 客户端当前用户为user2（uid=2000，gid=2000），映射成服务端的nfsnobody，只能读不能写

2. no_root_squash,no_all_squash,anonuid=1001,anongid=1001

• 客户端当前用户为root（uid=0，gid=0），正常读写；
• 客户端当前用户为test（uid=1001，gid=1001），映射成服务端的test，正常读写；
• 客户端当前用户为user1（uid=1001，gid=1001），映射成服务端的test，正常读写；
• 客户端当前用户为rancher（uid=1000，gid=1000），映射成服务端的rancher，只能读不能写；
• 客户端当前用户为user2（uid=2000，gid=2000），映射成服务端的nfsnobody（uid=1001，gid=1001），正常读写

3. root_squash,all_squash

只有1种情况：不管客户端当前用户是什么，均映射成服务端的nfsnobody，只能读不能写