fsGroup 与 supplementalGroups

Question

我运行我在 OpenShift 上部署，发现我需要 GID 2121 才能拥有写入权限。

当我尝试这个时，我似乎仍然没有写权限：

security:
  podSecurityContext: 
    fsGroup: 2121

这给了我一个 2121 is not an allowed group 错误。

但是，这似乎对我有用：

security:
  podSecurityContext: 
    fsGroup: 100010000  # original fsGroup value 
    supplementalGroups: [2121]

我想知道 fsGroup 和 supplementalGroups 的区别是什么。

我已经阅读了文档 here 并且还查看了 kubectl explain deployment.spec.template.spec.securityContext，但我仍然不太明白其中的区别。

我可以澄清一下不同的用例吗？

Answer 1

FSGroup 用于设置拥有 pod 卷的组。当 pod 挂载卷时，Kubernetes 将使用该组更改卷中所有文件的权限。

The owning GID will be the FSGroup

The setgid bit is set (new files created in the volume will be owned by FSGroup)

The permission bits are OR'd with rw-rw----

If unset, the Kubelet will not modify the ownership and permissions of any volume.

使用 FSGroup 时的一些注意事项：

更改慢速 and/or 大型文件系统的卷所有权可能会导致 pod 启动延迟。
这可能会损害使用同一卷的其他进程，如果它们进程没有访问新 GID 的权限。

SupplementalGroups - 控制可以将哪个补充组 ID 分配给 pod 中的进程。

A list of groups applied to the first process run in each container, in addition to the container's primary GID. If unspecified, no groups will be added to any container.

另外来自OpenShift documentation：

The recommended way to handle NFS access, assuming it is not an option to change permissions on the NFS export, is to use supplemental groups. Supplemental groups in OpenShift Container Platform are used for shared storage, of which NFS is an example. In contrast, block storage such as iSCSI uses the fsGroup SCC strategy and the fsGroup value in the securityContext of the pod.

fsGroup 与 supplementalGroups

fsGroup vs supplementalGroups

kubernetes

openshift