27.18.4. fsGroup

fsGroup 定义 pod 的"文件系统组"ID，该 ID 已添加到容器的补充组中。supplementalGroups ID 适用于共享存储，而 fsGroup ID 用于块存储。

块存储（如 Ceph RBD、iSCSI 和各种云存储）通常专用于单一 pod 请求块存储卷，可以是直接或使用 PVC。与共享存储不同，块存储被 pod 接管；也就是说，容器集定义（或镜像）中提供的用户和组 ID 被应用到实际的物理块设备。通常，块存储不被共享。

在以下 pod 定义片段中显示了 fsGroup 定义：

kind: Pod
...
spec:
  containers:
  - name: ...
  securityContext: 1
    fsGroup: 5555 2
  ...

与 supplementalGroups 一样，以上 Pod 中的所有容器（假设匹配的 SCC 或项目允许组 5555）将成为组 5555 的成员，并且有权访问块卷，而不管容器的用户 ID 是什么。如果 pod 与 restricted SCC 匹配，它的 fsGroup 策略是 MustRunAs，则 pod 将运行失败。但是，如果 SCC 的 fsGroup 策略设为 RunAsAny，则将接受任何 fsGroup ID（包括 5555）。请注意，如果 SCC 的 fsGroup 策略设置为 RunAsAny，并且未指定 fsGroup ID，则不会发生块存储的"接管"，则将拒绝该 Pod 的权限。

fsGroups 和 Custom SCCs

要补救上例中的情况，可以创建自定义 SCC，以便：

最好创建新 SCC，而不修改预定义的 SCC，或更改预定义项目中允许的 ID 范围。

请考虑以下片段的新 SCC 定义：

# oc get -o yaml --export scc new-scc
...
kind: SecurityContextConstraints
...
fsGroup:
  type: MustRunAs 1
  ranges: 2
  - max: 6000
    min: 5000 3
...

当上方所示的 pod 针对这个新 SCC 运行（假定为 course），pod 与新 SCC 匹配时，它将会启动，因为 Pod 定义中提供的组 5555 受到自定义 SCC 的限制。另外，pod 会"接管"块设备，因此当 pod 之外的进程查看块存储时，它实际上将具有 5555 作为其组 ID。

支持块所有权的卷列表包括：