提供 restricted SCC 的所有功能，但允许用户使用任何 UID 和任何 GID 运行。
×
管理安全上下文约束
在 OpenShift Dedicated 中，您可以使用安全上下文约束 (SCC) 来控制集群中 Pod 的权限。
默认 SCC 在安装过程中以及安装某些运算符或其他组件时创建。作为集群管理员，您还可以使用 OpenShift CLI (oc) 创建自己的 SCC。
|
请勿修改默认 SCC。自定义默认 SCC 可能会导致某些平台 Pod 部署时出现问题，或者在升级 OpenShift Dedicated 时出现问题。此外，在某些集群升级期间，默认 SCC 值将重置为默认值，这将丢弃对这些 SCC 的所有自定义。 不要修改默认 SCC，而是根据需要创建和修改您自己的 SCC。有关详细步骤，请参见 创建安全上下文约束。 |
|
在 OpenShift Dedicated 部署中，您只能为使用客户云订阅 (CCS) 模型的集群创建自己的 SCC。您无法为使用 Red Hat 云帐户的 OpenShift Dedicated 集群创建 SCC，因为 SCC 资源创建需要 |
关于安全上下文约束
与 RBAC 资源控制用户访问的方式类似，管理员可以使用安全上下文约束 (SCC) 来控制 Pod 的权限。这些权限决定 Pod 可以执行的操作以及可以访问的资源。您可以使用 SCC 来定义 Pod 必须运行的一组条件才能被系统接受。
安全上下文约束允许管理员控制
-
Pod 是否可以使用
allowPrivilegedContainer标志运行特权容器 -
Pod 是否使用
allowPrivilegeEscalation标志受到约束 -
容器可以请求的功能
-
将主机目录用作卷
-
容器的 SELinux 上下文
-
容器用户 ID
-
主机命名空间和网络的使用
-
拥有 Pod 卷的
FSGroup的分配 -
允许的补充组的配置
-
容器是否需要对其根文件系统进行写访问
-
卷类型的使用
-
允许的
seccomp配置文件的配置
|
请勿在 OpenShift Dedicated 中的任何命名空间上设置 |
默认安全上下文约束
集群包含下表中描述的几个默认安全上下文约束 (SCC)。当您将运算符或其他组件安装到 OpenShift Dedicated 时，可能会安装其他 SCC。
|
请勿修改默认 SCC。自定义默认 SCC 可能会导致某些平台 Pod 部署时出现问题，或者在升级 OpenShift Dedicated 时出现问题。此外，在某些集群升级期间，默认 SCC 值将重置为默认值，这将丢弃对这些 SCC 的所有自定义。 不要修改默认 SCC，而是根据需要创建和修改您自己的 SCC。有关详细步骤，请参见《创建安全上下文约束》。 |
| 安全上下文约束 | 描述 | ||
|---|---|---|---|
|
|||
|
提供 |
||
|
与
|
||
|
拒绝访问所有主机功能，并要求 Pod 使用分配给命名空间的 UID 和 SELinux 上下文运行。
在从 OpenShift Dedicated 4.10 或更早版本升级的集群中，任何经过身份验证的用户都可以使用此 SCC。对于新的 OpenShift Dedicated 4.11 或更高版本安装的用户，除非显式授予访问权限，否则 |
||
|
与
这是新安装提供的最严格的 SCC，并将默认用于经过身份验证的用户。
|
安全上下文约束设置
安全上下文约束 (SCC) 由控制 Pod 能够访问的安全功能的设置和策略组成。这些设置分为三类：
| 类别 | 描述 |
|---|---|
由布尔值控制 |
此类型的字段默认为最严格的值。例如，如果未指定， |
由允许集控制 |
此类型的字段将针对该集合进行检查，以确保其值是允许的。 |
由策略控制 |
具有生成值的策略的项目提供：
|
CRI-O 具有以下默认的允许 Pod 中每个容器使用的功能列表：
-
CHOWN -
DAC_OVERRIDE -
FSETID -
FOWNER -
SETGID -
SETUID -
SETPCAP -
NET_BIND_SERVICE -
KILL
容器使用此默认列表中的功能，但 Pod 清单作者可以通过请求其他功能或删除一些默认行为来更改此列表。使用 allowedCapabilities、defaultAddCapabilities 和 requiredDropCapabilities 参数来控制 Pod 的此类请求。使用这些参数，您可以指定可以请求哪些功能，哪些功能必须添加到每个容器，以及哪些功能必须禁止或从每个容器中删除。
|
您可以通过将 |
安全上下文约束策略
RunAsUser
-
MustRunAs- 要求配置runAsUser。使用配置的runAsUser作为默认值。根据配置的runAsUser进行验证。MustRunAs代码段示例... runAsUser: type: MustRunAs uid: <id> ... -
MustRunAsRange- 如果不使用预分配的值，则要求定义最小值和最大值。使用最小值作为默认值。根据整个允许范围进行验证。MustRunAsRange代码段示例... runAsUser: type: MustRunAsRange uidRangeMax: <maxvalue> uidRangeMin: <minvalue> ... -
MustRunAsNonRoot- 要求 Pod 使用非零runAsUser提交或在镜像中定义USER指令。不提供默认值。MustRunAsNonRoot代码段示例... runAsUser: type: MustRunAsNonRoot ... -
RunAsAny- 不提供默认值。允许指定任何runAsUser。RunAsAny代码段示例... runAsUser: type: RunAsAny ...
SELinuxContext
-
MustRunAs- 如果不使用预分配的值，则要求配置seLinuxOptions。使用seLinuxOptions作为默认值。根据seLinuxOptions进行验证。 -
RunAsAny- 不提供默认值。允许指定任何seLinuxOptions。
SupplementalGroups
-
MustRunAs- 如果不使用预分配的值，则要求至少指定一个范围。使用第一个范围的最小值作为默认值。根据所有范围进行验证。 -
RunAsAny- 不提供默认值。允许指定任何supplementalGroups。
FSGroup
-
MustRunAs- 如果不使用预分配的值，则要求至少指定一个范围。使用第一个范围的最小值作为默认值。根据第一个范围中的第一个 ID 进行验证。 -
RunAsAny- 不提供默认值。允许指定任何fsGroupID。
控制 CCS 集群的卷
可以通过设置 SCC 的 volumes 字段来控制使用具有客户云订阅 (CCS) 集群的 OpenShift Dedicated 的特定卷类型。
此字段的允许值对应于创建卷时定义的卷源。
-
photonPersistentDisk -
*（允许使用所有卷类型的特殊值。）
-
none（禁止使用所有卷类型的特殊值。仅出于向后兼容性而存在。）
对于新的 SCC，建议的最小允许卷集是 configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret 和 projected。
|
此允许卷类型列表并非详尽无遗，因为每次发布 OpenShift Dedicated 时都会添加新类型。 |
|
为了向后兼容性， |
准入控制
使用 SCC 的准入控制允许根据授予用户的权限控制资源的创建。
就 SCC 而言，这意味着准入控制器可以检查上下文中提供的用户信息以检索一组合适的 SCC。这样做可以确保 Pod 授权其操作环境或生成一组要应用于 Pod 的约束。
准入用于授权 Pod 的 SCC 集由用户身份和用户所属的组决定。此外，如果 Pod 指定服务帐户，则允许的 SCC 集包括服务帐户可以访问的任何约束。
|
创建工作负载资源（如部署）时，仅使用服务帐户来查找 SCC 并在其创建时接纳 Pod。 |
准入使用以下方法为 Pod 创建最终安全上下文：
-
检索所有可用的 SCC。
-
为请求中未指定的安全上下文设置生成字段值。
-
根据可用约束验证最终设置。
如果找到匹配的约束集，则接受 Pod。如果请求无法与 SCC 匹配，则拒绝 Pod。
Pod 必须根据 SCC 验证每个字段。以下是必须验证的两个字段的示例：
|
以下示例基于预分配值的策略。 |
MustRunAs 的 FSGroup SCC 策略
如果 Pod 定义了 fsGroup ID，则该 ID 必须等于默认 fsGroup ID。否则，该 Pod 不会通过该 SCC 的验证，系统将评估下一个 SCC。
如果 SecurityContextConstraints.fsGroup 字段的值为 RunAsAny，并且 Pod 规范省略了 Pod.spec.securityContext.fsGroup，则此字段被认为有效。请注意，在验证过程中，其他 SCC 设置可能会拒绝其他 Pod 字段，从而导致 Pod 失败。
MustRunAs 的 SupplementalGroups SCC 策略
如果 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 失败。
安全上下文约束优先级
安全上下文约束 (SCC) 具有优先级字段，该字段会影响准入控制器尝试验证请求时的顺序。
优先级值为 0 是最低优先级。空优先级被视为 0 或最低优先级。排序时，较高优先级的 SCC 将被移到集合的前面。
确定可用 SCC 的完整集合后，将按以下方式对 SCC 进行排序：
-
最高优先级的 SCC 首先排序。
-
如果优先级相同，则 SCC 将按从最严格到最不严格的顺序排序。
-
如果优先级和限制都相同，则 SCC 将按名称排序。
默认情况下，授予集群管理员的 anyuid SCC 在其 SCC 集中具有优先级。这允许集群管理员通过在 Pod 的 SecurityContext 中指定 RunAsUser 来以任何用户身份运行 Pod。
关于预分配的安全上下文约束值
准入控制器知道安全上下文约束 (SCC) 中的某些条件会触发它从命名空间查找预分配的值，并在处理 Pod 之前填充 SCC。每个 SCC 策略都独立于其他策略进行评估，允许使用预分配的值，每个策略的预分配值与 Pod 规范值聚合，以形成运行 Pod 中定义的各种 ID 的最终值。
以下 SCC 会在 Pod 规范中未定义范围时导致准入控制器查找预分配的值：
-
MustRunAsRange策略的RunAsUser，且未设置最小值或最大值。准入控制器将查找openshift.io/sa.scc.uid-range注解以填充范围字段。 -
MustRunAs策略的SELinuxContext，且未设置级别。准入控制器将查找openshift.io/sa.scc.mcs注解以填充级别。 -
MustRunAs策略的FSGroup。准入控制器将查找openshift.io/sa.scc.supplemental-groups注解。 -
MustRunAs策略的SupplementalGroups。准入控制器将查找openshift.io/sa.scc.supplemental-groups注解。
在生成阶段，安全上下文提供程序将对 Pod 中未明确设置的任何参数值使用默认值。默认值基于所选策略。
-
RunAsAny和MustRunAsNonRoot策略不提供默认值。如果 Pod 需要参数值（例如组 ID），则必须在 Pod 规范中定义该值。 -
MustRunAs（单值）策略提供始终使用的默认值。例如，对于组 ID，即使 Pod 规范定义了自己的 ID 值，命名空间的默认参数值也会出现在 Pod 的组中。 -
MustRunAsRange和MustRunAs（基于范围）策略提供范围的最小值。与单值MustRunAs策略一样，命名空间的默认参数值将出现在运行的 Pod 中。如果基于范围的策略可配置多个范围，则它将提供第一个配置范围的最小值。
|
如果命名空间上不存在 |
|
默认情况下，基于注解的 |
|
|
安全上下文约束示例
以下示例显示安全上下文约束 (SCC) 格式和注解
带注解的
privileged SCCallowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities: (1)
- '*'
apiVersion: security.openshift.io/v1
defaultAddCapabilities: [] (2)
fsGroup: (3)
type: RunAsAny
groups: (4)
- system:cluster-admins
- system:nodes
kind: SecurityContextConstraints
metadata:
annotations:
kubernetes.io/description: 'privileged allows access to all privileged and host
features and the ability to run as any user, any group, any fsGroup, and with
any SELinux context. WARNING: this is the most relaxed SCC and should be used
only for cluster administration. Grant with caution.'
creationTimestamp: null
name: privileged
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: null (5)
runAsUser: (6)
type: RunAsAny
seLinuxContext: (7)
type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups: (8)
type: RunAsAny
users: (9)
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
- system:serviceaccount:openshift-infra:build-controller
volumes: (10)
- '*'| 1 | Pod 可以请求的功能列表。空列表表示不能请求任何功能，而特殊符号 * 允许任何功能。 |
| 2 | 添加到任何 Pod 的附加功能列表。 |
| 3 | FSGroup 策略，它决定安全上下文的允许值。 |
| 4 | 可以访问此 SCC 的组。 |
| 5 | 要从 Pod 中删除的功能列表。或者，指定 ALL 以删除所有功能。 |
| 6 | runAsUser 策略类型，它决定安全上下文的允许值。 |
| 7 | seLinuxContext 策略类型，它决定安全上下文的允许值。 |
| 8 | supplementalGroups 策略，它决定安全上下文的允许补充组。 |
| 9 | 可以访问此 SCC 的用户。 |
| 10 | 安全上下文的允许卷类型。在示例中，* 允许使用所有卷类型。 |
SCC 上的 users 和 groups 字段控制哪些用户可以访问 SCC。默认情况下，集群管理员、节点和构建控制器被授予访问特权 SCC 的权限。所有已认证的用户都被授予访问 restricted-v2 SCC 的权限。
没有显式
runAsUser 设置apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext: (1)
containers:
- name: sec-ctx-demo
image: gcr.io/google-samples/node-hello:1.0| 1 | 当容器或 Pod 未请求其应运行的用户 ID 时，有效 UID 取决于发出此 Pod 的 SCC。由于 restricted-v2 SCC 默认授予所有已认证的用户，因此它将对所有用户和服务帐户可用，并在大多数情况下使用。restricted-v2 SCC 使用 MustRunAsRange 策略来约束和默认为 securityContext.runAsUser 字段的可能值。准入插件将查找当前项目上的 openshift.io/sa.scc.uid-range 注解以填充范围字段，因为它不提供此范围。最终，容器的 runAsUser 将等于范围的第一个值，该值难以预测，因为每个项目都有不同的范围。 |
有显式
runAsUser 设置apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000 (1)
containers:
- name: sec-ctx-demo
image: gcr.io/google-samples/node-hello:1.0| 1 | 仅当为某个服务账号或用户授予了允许此类用户 ID 的 SCC 访问权限时，OpenShift Dedicated 才会接受请求特定用户 ID 的容器或 Pod。SCC 可以允许任意 ID、某个范围内的 ID 或请求的特定用户 ID。 |
此配置对 SELinux、fsGroup 和补充组有效。
为 CCS 集群创建安全上下文约束
如果默认安全上下文约束 (SCC) 不满足您的应用程序工作负载要求，您可以使用 OpenShift CLI (oc) 创建自定义 SCC。
|
创建和修改您自己的 SCC 是高级操作，可能会导致集群不稳定。如果您对使用自己的 SCC 有任何疑问，请联系 Red Hat 支持。有关联系 Red Hat 支持的信息，请参阅《获取支持》。 |
|
在 OpenShift Dedicated 部署中，您只能为使用客户云订阅 (CCS) 模型的集群创建自己的 SCC。您无法为使用 Red Hat 云帐户的 OpenShift Dedicated 集群创建 SCC，因为 SCC 资源创建需要 |
先决条件
-
安装 OpenShift CLI (
oc)。 -
以具有
cluster-admin角色的用户身份登录集群。
步骤
-
在名为
scc-admin.yaml的 YAML 文件中定义 SCCkind: SecurityContextConstraints apiVersion: security.openshift.io/v1 metadata: name: scc-admin allowPrivilegedContainer: true runAsUser: type: RunAsAny seLinuxContext: type: RunAsAny fsGroup: type: RunAsAny supplementalGroups: type: RunAsAny users: - my-admin-user groups: - my-admin-group或者，您可以通过使用所需的值设置
requiredDropCapabilities字段来为 SCC 删除特定功能。任何指定的功能都将从容器中删除。要删除所有功能，请指定ALL。例如，要创建一个删除KILL、MKNOD和SYS_CHROOT功能的 SCC，请将以下内容添加到 SCC 对象中requiredDropCapabilities: - KILL - MKNOD - SYS_CHROOT您不能在一个
allowedCapabilities和requiredDropCapabilities中同时列出功能。CRI-O 支持与Docker 文档中相同的可用性值列表。
-
通过传入文件创建 SCC
$ oc create -f scc-admin.yaml示例输出securitycontextconstraints "scc-admin" created
验证
-
验证 SCC 是否已创建
$ oc get scc scc-admin示例输出NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES scc-admin true [] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk gitRepo glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]
配置工作负载以要求特定的 SCC
您可以将工作负载配置为需要特定的安全上下文约束 (SCC)。这在您想将特定 SCC 固定到工作负载或想防止所需 SCC 被集群中的另一个 SCC 抢占的场景中很有用。
要要求特定的 SCC，请在工作负载上设置 openshift.io/required-scc 注解。您可以将此注解设置在可以设置 Pod 清单模板的任何资源上，例如部署或守护程序集。
SCC 必须存在于集群中，并且必须适用于工作负载，否则 Pod 准入将失败。如果创建 Pod 的用户或 Pod 的服务帐户对 Pod 命名空间中的 SCC 具有 use 权限，则 SCC 被认为适用于该工作负载。
|
不要更改活动 Pod 清单中的 |
先决条件
-
SCC 必须存在于集群中。
步骤
-
为部署创建一个 YAML 文件，并通过设置
openshift.io/required-scc注解来指定所需的 SCC示例deployment.yamlapiVersion: config.openshift.io/v1 kind: Deployment apiVersion: apps/v1 spec: # ... template: metadata: annotations: openshift.io/required-scc: "my-scc" (1) # ...1 指定要请求的 SCC 的名称。 -
运行以下命令创建资源
$ oc create -f deployment.yaml
验证
-
验证部署是否使用了指定的 SCC
-
运行以下命令查看 Pod 的
openshift.io/scc注解的值$ oc get pod <pod_name> -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}' (1)1 将 <pod_name>替换为您的部署 Pod 的名称。 -
检查输出并确认显示的 SCC 与您在部署中定义的 SCC 匹配
示例输出my-scc
-
基于角色的安全上下文约束访问
您可以将 SCC 指定为由 RBAC 处理的资源。这允许您将对 SCC 的访问范围限定到某个项目或整个集群。将用户、组或服务帐户直接分配到 SCC 将保留集群范围。
|
不要在默认项目中运行工作负载或共享对默认项目的访问。默认项目保留用于运行核心集群组件。 以下默认项目被认为是高度特权的： |
要为您的角色包含对 SCC 的访问权限，请在创建角色时指定 scc 资源。
$ oc create role <role-name> --verb=use --resource=scc --resource-name=<scc-name> -n <namespace>这将产生以下角色定义
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
...
name: role-name (1)
namespace: namespace (2)
...
rules:
- apiGroups:
- security.openshift.io (3)
resourceNames:
- scc-name (4)
resources:
- securitycontextconstraints (5)
verbs: (6)
- use| 1 | 角色的名称。 |
| 2 | 定义的角色的命名空间。如果未指定，则默认为 default。 |
| 3 | 包含 SecurityContextConstraints 资源的 API 组。当 scc 指定为资源时自动定义。 |
| 4 | 您希望访问的 SCC 的示例名称。 |
| 5 | 允许用户在 resourceNames 字段中指定 SCC 名称的资源组的名称。 |
| 6 | 应用于角色的一系列动词。 |
具有此类规则的本地或集群角色允许与其绑定到角色绑定或集群角色绑定的主体使用名为 scc-name 的用户定义的 SCC。
|
由于 RBAC 旨在防止升级，即使是项目管理员也无法授予对 SCC 的访问权限。默认情况下，他们不允许对 SCC 资源使用动词 |
安全上下文约束命令参考
您可以使用 OpenShift CLI (oc) 将安全上下文约束 (SCC) 作为普通 API 对象在您的实例中进行管理。
列出安全上下文约束
要获取 SCC 的当前列表
$ oc get scc示例输出
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES
anyuid false <no value> MustRunAs RunAsAny RunAsAny RunAsAny 10 false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
hostaccess false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","hostPath","persistentVolumeClaim","projected","secret"]
hostmount-anyuid false <no value> MustRunAs RunAsAny RunAsAny RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","hostPath","nfs","persistentVolumeClaim","projected","secret"]
hostnetwork false <no value> MustRunAs MustRunAsRange MustRunAs MustRunAs <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
hostnetwork-v2 false ["NET_BIND_SERVICE"] MustRunAs MustRunAsRange MustRunAs MustRunAs <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
node-exporter true <no value> RunAsAny RunAsAny RunAsAny RunAsAny <no value> false ["*"]
nonroot false <no value> MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
nonroot-v2 false ["NET_BIND_SERVICE"] MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
privileged true ["*"] RunAsAny RunAsAny RunAsAny RunAsAny <no value> false ["*"]
restricted false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
restricted-v2 false ["NET_BIND_SERVICE"] MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]检查安全上下文约束
您可以查看有关特定 SCC 的信息，包括应用了 SCC 的用户、服务帐户和组。
例如，要检查 restricted SCC
$ oc describe scc restricted示例输出
Name: restricted
Priority: <none>
Access:
Users: <none> (1)
Groups: <none> (2)
Settings:
Allow Privileged: false
Allow Privilege Escalation: true
Default Add Capabilities: <none>
Required Drop Capabilities: KILL,MKNOD,SETUID,SETGID
Allowed Capabilities: <none>
Allowed Seccomp Profiles: <none>
Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret
Allowed Flexvolumes: <all>
Allowed Unsafe Sysctls: <none>
Forbidden Sysctls: <none>
Allow Host Network: false
Allow Host Ports: false
Allow Host PID: false
Allow Host IPC: false
Read Only Root Filesystem: false
Run As User Strategy: MustRunAsRange
UID: <none>
UID Range Min: <none>
UID Range Max: <none>
SELinux Context Strategy: MustRunAs
User: <none>
Role: <none>
Type: <none>
Level: <none>
FSGroup Strategy: MustRunAs
Ranges: <none>
Supplemental Groups Strategy: RunAsAny
Ranges: <none>| 1 | 列出应用了 SCC 的用户和服务帐户。 |
| 2 | 列出应用了 SCC 的组。 |