OpenShift环境下fsGroup与supplementalGroups区别及适用场景咨询

你遇到的「2121 is not an allowed group」报错本质是OpenShift默认安全上下文约束（SCC）对fsGroup的取值范围做了限制：每个OpenShift项目默认会分配一段独占的数值区间作为合法的用户/组ID范围，你配置中的100010000就是当前项目分配的合法fsGroup值，直接将自定义的小GID 2121设为fsGroup会被SCC规则拦截。

1. fsGroup #

• 是卷默认属组配置：Kubelet会主动将Pod挂载的所有持久卷的属组修改为fsGroup指定的GID，同时会给卷设置对应组读写权限，权限修改行为可通过fsGroupChangePolicy调整
• 是容器进程的默认附加组：容器内运行的所有进程，所属组列表默认会包含fsGroup指定的GID，进程在容器内新创建的文件也会默认继承这个属组
• 取值受集群/项目规则限制：OpenShift、托管K8s服务通常会限制fsGroup的可取值范围，避免权限逃逸

2. supplementalGroups #

• 是额外附加组列表：仅会将指定的GID加入到容器进程的所属组列表中，不会修改任何持久卷的属组和权限
• 取值限制宽松：绝大多数场景下集群不会限制supplementalGroups的可取值范围，允许传入任意自定义GID
• 你的场景正常运行的原因：目标存储本身的属组已经预设为2121，容器进程只要加入2121这个附加组即可拿到写入权限，不需要修改卷的属组，因此不需要把2121设为fsGroup

• 适合使用fsGroup的场景：
  • 使用emptyDir、hostPath或者新创建的未预设权限的PVC，需要K8s自动修改卷权限让容器进程可读写
  • 需要容器内新创建的文件默认继承指定属组，方便同Pod内其他容器或者后续Pod访问
  • 所用GID在集群/项目允许的fsGroup取值范围内
• 适合使用supplementalGroups的场景：
  • 使用的PVC已经预设了固定属组（比如共享存储、NAS卷提前分配了权限），不需要修改卷属组，仅需要进程拿到对应组权限
  • 需要同时访问多个不同属组的存储，进程需要加入多个附加组
  • 需要使用的GID不在集群/项目允许的fsGroup取值范围内，无法直接设置为fsGroup

内容的提问来源于stack exchange，提问作者Kun Hwi Ko