27.2.4. NFS 卷安全性
这部分论述了 NFS 卷安全性，其中包括匹配的权限和 SELinux 考虑。用户需要了解 POSIX 权限、进程 UID 、supplemental 组和 SELinux 的基本知识。
在实施 NFS 卷前，请查看完整的卷安全性 主题。
开发人员在其 Pod 定义的 volumes 部分（按名称或 NFS 卷插件）中引用 NFS 存储来请求 NFS 存储。
NFS 服务器中的 /etc/exports 文件包含可访问的 NFS 目录。目标 NFS 目录有 POSIX 拥有者和组群 ID。OpenShift Container Platform NFS 插件使用相同的 POSIX 所有者权限及在导出的 NFS 目录中找到的权限挂载容器的 NFS 目录。然而，容器实际运行时所使用的 UID 与 NFS 挂载的所有者的 UID 不同。这是所需的行为。
例如，目标 NFS 目录在 NFS 服务器中，如下所示：
# ls -lZ /opt/nfs -d drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0 /opt/nfs # id nfsnobody uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)
然后，容器必须与 SELinux 标签匹配，并使用 UID 65534（nfsnobody 的所有者）或其 supplemental 组的 5555 运行，才能访问该目录。
所有者 ID 65534 只是一个示例。虽然 NFS 的 root_squash 将 root (0)映射到 nfsnobody (65534)），但 NFS 导出可以具有任意所有者 ID。NFS 导出的所有者不需要 65534。
27.2.4.1. 组 ID
处理 NFS 访问（假设这不是更改 NFS 导出权限的选项）是使用补充组。OpenShift Container Platform 中的附件组的功能是用于共享存储（NFS 是一个共享存储）。与之相反，块存储（如 Ceph RBD 或 iSCSI）使用 fsGroup SCC 策略和在 pod 的 securityContext 中的 fsGroup 值。
通常情况下，最好使用附件组群 ID 而不是用户 ID 来获得对持久性存储的访问。在完整的 卷安全主题中会进一步阐述 补充组。
因为上面显示的示例目标 NFS 目录上的组 ID 是 5555，所以 pod 可以使用 pod 级 securityContext 定义下的 supplementalGroups 来定义组 ID。例如：
spec:
containers:
- name:
...
securityContext: 1
supplementalGroups: [5555] 2
假设没有可能满足 Pod 要求的自定义 SCC，Pod 可能与受限 SCC 匹配。此 SCC 将 supplementalGroups 策略设置为 RunAsAny，表示任何提供的组 ID 都被接受而无需范围检查。
因此，上面的 pod 可以通过，并被启动。但是，如果需要进行组 ID 范围检查，一个自定义 SCC，如 Pod 安全性和自定义 SCC 中所述，这是首选的解决方案。可创建一个定义了最小和最大组群 ID 的自定义 SCC，这样就会强制进行组 ID 范围检查，组 ID 5555 将被允许 。
要使用自定义 SCC，需要首先将其添加到适当的服务帐户（service account）中。例如，在一个特定项目中使用 default 服务账户（除非在 pod 规格中指定了另外一个账户）。详情请参阅 向用户、组或项目添加 SCC。
