提供restricted SCC的所有功能，但允许用户以任何UID和任何GID运行。
×
管理安全上下文约束
在AWS上的Red Hat OpenShift Service中，您可以使用安全上下文约束（SCC）来控制集群中Pod的权限。
默认SCC在安装过程中以及安装某些Operators或其他组件时创建。作为集群管理员，您也可以使用OpenShift CLI（oc）创建自己的SCC。
|
不要修改默认SCC。自定义默认SCC可能会导致某些平台Pod部署或ROSA升级时出现问题。此外，在某些集群升级期间，默认SCC值将重置为默认值，这将丢弃对这些SCC的所有自定义。 不要修改默认SCC，而是根据需要创建和修改您自己的SCC。有关详细步骤，请参阅创建安全上下文约束。 |
关于安全上下文约束
与RBAC资源控制用户访问的方式类似，管理员可以使用安全上下文约束（SCC）来控制Pod的权限。这些权限决定了Pod可以执行的操作以及可以访问的资源。您可以使用SCC来定义Pod必须运行的一组条件才能被系统接受。
安全上下文约束允许管理员控制
-
Pod是否可以使用
allowPrivilegedContainer标志运行特权容器 -
Pod是否使用
allowPrivilegeEscalation标志受到约束 -
容器可以请求的功能
-
将主机目录用作卷
-
容器的SELinux上下文
-
容器用户ID
-
主机命名空间和网络的使用
-
拥有Pod卷的
FSGroup的分配 -
允许的补充组的配置
-
容器是否需要对其根文件系统写入访问权限
-
卷类型的使用
-
允许的
seccomp配置文件的配置
|
不要在AWS上的Red Hat OpenShift Service中的任何命名空间上设置 |
默认安全上下文约束
集群包含下表中描述的几个默认安全上下文约束（SCC）。当您将Operators或其他组件安装到AWS上的Red Hat OpenShift Service时，可能会安装其他SCC。
|
不要修改默认SCC。自定义默认SCC可能会导致某些平台Pod部署或ROSA升级时出现问题。此外，在某些集群升级期间，默认SCC值将重置为默认值，这将丢弃对这些SCC的所有自定义。 不要修改默认SCC，而是根据需要创建和修改您自己的SCC。有关详细步骤，请参阅“创建安全上下文约束”。 |
| 安全上下文约束 | 描述 | ||||
|---|---|---|---|---|---|
|
|||||
|
允许访问所有主机命名空间，但仍然要求Pod以分配给命名空间的UID和SELinux上下文运行。
|
||||
|
提供
|
||||
|
允许使用主机网络和主机端口，但仍然要求Pod以分配给命名空间的UID和SELinux上下文运行。
|
||||
|
与
|
||||
|
用于Prometheus节点导出器。
|
||||
|
提供 |
||||
|
与
|
||||
|
允许访问所有特权和主机功能，并能够以任何用户、任何组、任何 FSGroup 以及任何 SELinux 上下文运行。
|
||||
|
拒绝访问所有主机功能，并要求 Pod 使用分配给命名空间的 UID 和 SELinux 上下文运行。
在从 Red Hat OpenShift Service on AWS 4.10 或更早版本升级的集群中，任何已认证用户都可以使用此 SCC。除非显式授予访问权限，否则在新的 Red Hat OpenShift Service on AWS 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。
控制卷
可以通过设置 SCC 的volumes字段来控制特定卷类型的使用。
此字段的允许值对应于创建卷时定义的卷源
-
photonPersistentDisk -
*（允许使用所有卷类型的特殊值。）
-
none（禁止使用所有卷类型的特殊值。仅出于向后兼容性而存在。）
对于新的 SCC，建议的最小允许卷集为configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret和projected。
|
此允许卷类型列表并不详尽，因为 Red Hat OpenShift Service on AWS 的每个版本都会添加新的类型。 |
|
为了向后兼容性， |
准入控制
使用 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。否则，该 SCC 不会验证 Pod，并且会评估下一个 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。否则，该 SCC 不会验证 Pod，并且会评估下一个 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 的访问权限时，请求特定用户 ID 的容器或 Pod 才会被 Red Hat OpenShift Service on AWS 接受。SCC 可以允许任意 ID、属于某个范围内的 ID 或请求特有的确切用户 ID。 |
此配置对 SELinux、fsGroup 和补充组有效。
创建安全上下文约束
如果默认的安全上下文约束 (SCC) 不满足您的应用程序工作负载要求，您可以使用 OpenShift CLI (oc) 创建自定义 SCC。
|
创建和修改您自己的 SCC 是高级操作，可能会导致集群不稳定。如果您对使用自己的 SCC 有任何疑问，请联系 Red Hat 支持。有关联系 Red Hat 支持的信息，请参阅《获取支持》。 |
先决条件
-
安装 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 的组。 |