Openshift部署中EFS共享卷挂载组权限不足问题咨询

1. 核对EFS访问点配置的实际生效权限 #

• 确认EFS访问点的POSIX用户配置是否和预期一致：要保证访问点配置的GID为5555，同时目录权限配置的组权限位包含读写执行权限，比如0775，如果当前访问点配置的目录属主是其他GID，或者组权限只有读执行，就会出现权限不足
• 检查是否配置了EFS访问点的根目录路径：如果挂载时没有指定正确的访问点路径，会直接挂载EFS根目录，默认根目录权限是root:root 755，补充组配置无法生效

2. 检查Openshift PV/PVC配置是否正确关联访问点 #

• 确认PV的spec.csi.volumeHandle参数是否正确填写了EFS文件系统ID::访问点ID的格式，漏写访问点ID会直接挂载EFS根目录，无法继承访问点权限
• 查看PV的spec.mountOptions是否包含tls参数，部分EFS CSI驱动版本要求开启tls才能正确应用访问点权限
• 确认PVC的storageClassName和PV对应，没有被动态供给自动创建新的未绑定访问点的PV

3. 排查SecurityContext的生效范围 #

• 如果你配置的securityContext是写在容器级别而非Pod级别，supplementalGroups参数不会生效，必须配置在spec.template.spec.securityContext（Pod级）才会对所有容器生效
• 检查Openshift项目的SCC（安全上下文约束）是否允许配置supplementalGroups：默认的restricted SCC可能会覆盖补充组配置，可以执行oc describe scc restricted查看是否有MustRunAs之类的组限制，如有需要可以给对应服务账号绑定自定义SCC放开组限制

4. 运行时权限验证 #

• 进入Pod后手动执行touch /挂载路径/events/test查看具体报错信息
• 执行ls -n /挂载路径查看目录的数值UID/GID，不要看用户名映射，避免Pod内用户ID和主机/EFS端的用户名映射不一致导致的误判
• 如果是Openshift 4.x版本默认使用随机UID，你可以额外在securityContext中配置fsGroup: 5555，触发Kubernetes在挂载卷时自动修改卷的权限为对应组所有

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