27.18.5. 用户 ID
在使用补充组之前，请阅读 SCC、defaults 和 Allowed Ranges。
与使用用户 ID 相比，通常最好使用组 ID（supplemental 或 fsGroup）来获得对持久性存储的访问。
用户 ID 可以在容器镜像或容器集定义中定义。在 pod 定义中，单个用户 ID 可以全局定义到所有容器，或特定于单个容器（或两者）。用户 ID 包括在 pod 定义片段中：
spec:
containers:
- name: ...
securityContext:
runAsUser: 1000100001
上述中的 ID 1000100001 是特定于容器的，与导出上的所有者 ID 匹配。如果 NFS 导出的所有者 ID 是 54321，则该数字将在 pod 定义中使用。指定容器定义之外的 securityContext 会将 ID 全局提供给 pod 中的所有容器。
与组 ID 类似，用户 ID 可能会根据 SCC 和/或项目中设置的策略来验证。如果 SCC 的 runAsUser 策略设为 RunAsAny，则允许容器集定义或镜像中定义的任何用户 ID。
这意味着允许 UID 0 (root)。
如果设为 MustRunAsRange，则 runAsUser 策略被设置为 MustRunAsRange，则提供的用户 ID 将会根据允许 ID 的范围进行验证。如果 pod 没有提供用户 ID，则默认 ID 被设置为允许的用户 ID 范围的最小值。
返回先前的 NFS 示例，容器需要将其 UID 设定为 1000100001，这显示在上面的 pod 片段中。假设 默认项目 和 restricted SCC，则不允许 Pod 请求的用户 ID 1000100001，因此 pod 将失败。pod 失败，因为：
- 它将请求 1000100001 作为其用户 ID，
-
所有可用的 SCC 使用 MustRunAsRange 作为其
runAsUser策略，因此需要 UID 范围检查， - 1000100001 不包含在 SCC 或项目用户 ID 范围内。
要避免这种情况，可以使用适当的用户 ID 范围创建新的 SCC。还可以通过定义适当的用户 ID 范围创建新项目。另外还有其他首选选项：
- 可将 restricted SCC 修改为在最小和最大用户 ID 范围内包含 1000100001。不建议这样做，否则应避免在可能的情况下修改预定义的 SCC。
-
restricted SCC 可以修改为使用 RunAsAny 作为
runAsUser值，从而消除 ID 范围检查。强烈建议不要这样做，因为容器可以以 root 用户身份运行。 - 默认 项目的 UID 范围可以更改，以允许用户 ID 1000100001。这通常不建议，因为只能指定单个用户 ID，因此如果更改了范围，则其他 pod 可能无法运行。
用户 ID 和自定义 SCC
最好避免在可能的情况下修改预定义的 SCC。首选方法是创建一个最适合组织安全需求的自定义 SCC，或 创建一个 支持所需用户 ID 的新项目。
要补救上例中的情况，可以创建自定义 SCC，以便：
- 已定义最小和最大用户 ID，
- UID 范围检查仍会被强制使用，
- 允许使用 1000100001 的 UID。
例如：
$ oc get -o yaml --export scc nfs-scc allowHostDirVolumePlugin: false 1 ... kind: SecurityContextConstraints metadata: ... name: nfs-scc 2 priority: 9 3 requiredDropCapabilities: null runAsUser: type: MustRunAsRange 4 uidRangeMax: 1000100001 5 uidRangeMin: 1000100001 ...
现在，使用 runAsUser：上一个 pod 定义片段中显示的 1000100001，pod 与新的 nfs-scc 匹配，且 UID 为 1000100001。
