27.18.3. 补充组

补充组是常规的 Linux 组。当进程在 Linux 中运行时，它具有一个 UID、一个 GID，以及一个或多个补充组。可以为容器的主进程设置这些属性。supplementalGroups ID 通常用于控制对共享存储的访问，如 NFS 和 GlusterFS，而 fsGroup 则用于控制对块存储的访问，如 Ceph RBD 和 iSCSI。

OpenShift Container Platform 共享存储插件挂载卷，以便挂载上的 POSIX 权限与目标存储上的权限匹配。例如，如果目标存储的所有者 ID 是 1234，其组 ID 为 5678，则主机节点上和容器中的挂载将具有同样的 ID。因此，容器的主进程必须匹配其中一个或两个 ID 才能访问该卷。

例如，请考虑以下 NFS 导出：

在 OpenShift Container Platform 节点上：

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs  *

在 NFS 服务器中：

# cat /etc/exports
/opt/nfs *(rw,sync,root_squash)
...

# ls -lZ /opt/nfs -d
drwx------. 1000100001 5555 unconfined_u:object_r:usr_t:s0   /opt/nfs

/opt/nfs/ 导出可以被 UID 1000100001 和组 5555 访问。通常，容器不应以 root 用户身份运行。因此，在这个 NFS 示例中，没有以 UID 1000100001 运行且不是组 5555 的容器将无法访问 NFS 导出。

通常，与 pod 匹配的 SCC 不允许指定特定用户 ID，因此使用补充组可以更加灵活地向 pod 授予存储访问权限。例如，要向导出授予 NFS 访问权限，可在 Pod 定义中定义组 5555 ：

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - name: ...
    volumeMounts:
    - name: nfs 1
      mountPath: /usr/share/... 2
  securityContext: 3
    supplementalGroups: [5555] 4
  volumes:
  - name: nfs 5
    nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs 6

以上 pod 中的所有容器（假设匹配的 SCC 或项目允许组 5555）成为组 5555 的成员，并且无论容器的用户 ID 都有权访问该卷。但是，上述假设至关重要。有时，SCC 并不定义允许的组 ID 范围，而是需要组 ID 验证（s supplementalGroups 的结果设置为 MustRunAs）。请注意，这不是 restricted SCC 的情况。该项目不太可能允许组 ID 5555，除非项目自定义了用于访问此 NFS 导出。因此，在这种情况下，上面的 Pod 将失败，因为它组 ID 5555 不在 SCC 或项目的允许组 ID 中。

补充组和自定义 SCC

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

创建新 SCC 而非修改预定义的 SCC，或更改预定义项目中允许的 ID 范围，通常是创建新的 SCC。

创建新 SCC 的最简单方法是导出现有的 SCC，并自定义 YAML 文件以满足新 SCC 的要求。例如：

以下是名为 nfs-scc 的新 SCC 片段：

$ oc get -o yaml --export scc nfs-scc

allowHostDirVolumePlugin: false 1
...
kind: SecurityContextConstraints
metadata:
  ...
  name: nfs-scc 2
priority: 9 3
...
supplementalGroups:
  type: MustRunAs 4
  ranges:
  -  min: 5000 5
     max: 6000
...

如果前面显示的相同 pod 针对这个新 SCC 运行（假设，pod 与新 SCC 匹配时），它将会启动，因为 Pod 定义中提供的组 5555 可以被自定义 SCC 支持。