4.2.5.5. 准入
利用 SCC 的准入控制可以根据授予用户的能力来控制资源的创建。
就 SCC 而言，这意味着准入控制器可以检查上下文中提供的用户信息以检索一组合适的 SCC。这样做可确保 Pod 具有相应的授权，能够提出与其操作环境相关的请求或生成一组要应用到 Pod 的约束。
准入用于授权 Pod 的 SCC 集合由用户身份和用户所属的组来决定。另外，如果 Pod 指定了服务帐户，则允许的 SCC 集合包括服务帐户可访问的所有约束。
准入使用以下方法来创建 Pod 的最终安全性上下文：
- 检索所有可用的 SCC。
- 为请求上未指定的安全性上下文设置生成字段值。
- 针对可用约束来验证最终设置。
如果找到了匹配的约束集合，则接受 Pod。如果请求不能与 SCC 匹配，则拒绝 Pod。
Pod 必须针对 SCC 验证每一个字段。以下示例中只有其中两个字段必须验证：
这些示例是在使用预分配值的策略的上下文中。
FSGroup SCC 策略为 MustRunAs
如果 Pod 定义了 fsGroup ID，该 ID 必须等于默认的 fsGroup ID。否则，Pod 不会由该 SCC 验证，而会评估下一个 SCC。
如果 SecurityContextConstraints.fsGroup 字段的值为 RunAsAny，并且 Pod 规格省略了 Pod.spec.securityContext.fsGroup，则此字段被视为有效。注意在验证过程中，其他 SCC 设置可能会拒绝其他 Pod 字段，从而导致 Pod 失败。
SupplementalGroups SCC 策略为 MustRunAs
如果 Pod 规格定义了一个或多个 supplementalGroups ID，则 Pod 的 ID 必须等于命名空间的 openshift.io/sa.scc.supplemental-groups 注解中的某一个 ID。否则，Pod 不会由该 SCC 验证，而会评估下一个 SCC。
如果 SecurityContextConstraints.supplementalGroups 字段的值为 RunAsAny，并且 Pod 规格省略了 Pod.spec.securityContext.supplementalGroups，则此字段被视为有效。注意在验证过程中，其他 SCC 设置可能会拒绝其他 Pod 字段，从而导致 Pod 失败。
4.2.5.5.1. SCC 优先级
SCC 有一个优先级字段，它会影响准入控制器尝试验证请求时的排序。在排序时，高优先级 SCC 移到集合的前面。确定了可用 SCC 的完整集合后，按照以下方式排序：
- 优先级最高的在前，nil 视为 0 优先级
- 如果优先级相等，则 SCC 按照限制性最强到最弱排序
- 如果优先级和限制性都相等，则 SCC 按照名称排序
默认情况下，授予集群管理员的 anyuid SCC 在 SCC 集合中具有优先权。这使得集群管理员能够以任意用户运行 Pod，而不必在 Pod 的 SecurityContext 中指定 RunAsUser。若有需要，管理员仍然可以指定 RunAsUser。
