提供 restricted SCC 的所有功能，但允许用户使用任何 UID 和任何 GID 运行。
×
管理安全上下文约束
在 OpenShift Container Platform 中，您可以使用安全上下文约束 (SCC) 来控制集群中 Pod 的权限。
默认 SCC 在安装过程中以及安装某些运算符或其他组件时创建。作为集群管理员，您还可以使用 OpenShift CLI (oc) 创建自己的 SCC。
|
不要修改默认 SCC。自定义默认 SCC 可能会导致某些平台 Pod 部署或 OpenShift Container Platform 升级时出现问题。此外，在某些集群升级期间，默认 SCC 值将重置为默认值，这将丢弃对这些 SCC 的所有自定义。 不要修改默认 SCC，而是根据需要创建和修改您自己的 SCC。有关详细步骤，请参阅 创建安全上下文约束。 |
关于安全上下文约束
与 RBAC 资源控制用户访问的方式类似，管理员可以使用安全上下文约束 (SCC) 来控制 Pod 的权限。这些权限决定 Pod 可以执行的操作以及可以访问的资源。您可以使用 SCC 来定义 Pod 必须运行的一组条件才能被系统接受。
安全上下文约束允许管理员控制
-
Pod 是否可以使用
allowPrivilegedContainer标志运行特权容器 -
Pod 是否使用
allowPrivilegeEscalation标志受到约束 -
容器可以请求的功能
-
将主机目录用作卷
-
容器的 SELinux 上下文
-
容器用户 ID
-
主机命名空间和网络的使用
-
拥有 Pod 卷的
FSGroup的分配 -
允许的补充组的配置
-
容器是否需要对其根文件系统的写访问权限
-
卷类型的使用
-
允许的
seccomp配置文件的配置
|
不要在 OpenShift Container Platform 中的任何命名空间上设置 |
默认安全上下文约束
集群包含下表中描述的几个默认安全上下文约束 (SCC)。当您将运算符或其他组件安装到 OpenShift Container Platform 时，可能会安装其他 SCC。
|
不要修改默认 SCC。自定义默认 SCC 可能会导致某些平台 Pod 部署或 OpenShift Container Platform 升级时出现问题。此外，在某些集群升级期间，默认 SCC 值将重置为默认值，这将丢弃对这些 SCC 的所有自定义。 不要修改默认 SCC，而是根据需要创建和修改您自己的 SCC。有关详细步骤，请参阅“创建安全上下文约束”。 |
| 安全上下文约束 | 描述 | ||||
|---|---|---|---|---|---|
|
|||||
|
允许访问所有主机命名空间，但仍然要求以分配给命名空间的 UID 和 SELinux 上下文运行 Pod。
|
||||
|
提供
|
||||
|
允许使用主机网络和主机端口，但仍然要求以分配给命名空间的 UID 和 SELinux 上下文运行 Pod。
|
||||
|
与
|
||||
|
用于 Prometheus 节点导出器。
|
||||
|
提供 |
||||
|
与
|
||||
|
允许访问所有特权和主机功能，并能够以任何用户、任何组、任何 FSGroup 以及任何 SELinux 上下文运行。
|
||||
|
拒绝访问所有主机功能，并要求以分配给命名空间的 UID 和 SELinux 上下文运行 Pod。
在从 OpenShift Container Platform 4.10 或更早版本升级的集群中，任何经过身份验证的用户都可以使用此 SCC。对于新的 OpenShift Container Platform 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- 要求使用非零runAsUser提交 Pod，或者在映像中定义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。
|
此允许卷类型列表并不详尽，因为每次发布OpenShift Container Platform时都会添加新类型。 |
|
为了向后兼容， |
准入控制
使用SCC的准入控制允许根据授予用户的权限来控制资源的创建。
就SCC而言，这意味着准入控制器可以检查上下文中提供的用户信息以检索一组合适的SCC。这样做可以确保pod被授权发出关于其运行环境的请求，或生成一组要应用于pod的约束。
准入控制用于授权pod的SCC集由用户的身份和用户所属的组决定。此外，如果pod指定了一个服务帐户，则允许的SCC集包括服务帐户可以访问的任何约束。
|
创建工作负载资源（如部署）时，只有服务帐户用于查找SCC并在创建pod时准入它们。 |
准入控制使用以下方法为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失败。
关于预分配的安全上下文约束值
准入控制器知道安全上下文约束 (SCC) 中的某些条件会触发它从命名空间查找预分配的值，并在处理pod之前填充SCC。每个SCC策略都独立于其他策略进行评估，其中允许的预分配值用于每个策略，并与pod规范值聚合以构成运行pod中定义的各种ID的最终值。
以下SCC会在pod规范中未定义范围时导致准入控制器查找预分配的值：
-
RunAsUser策略为MustRunAsRange，且未设置最小值或最大值。准入控制会查找openshift.io/sa.scc.uid-range注释以填充范围字段。 -
SELinuxContext策略为MustRunAs，且未设置级别。准入控制会查找openshift.io/sa.scc.mcs注释以填充级别。 -
FSGroup策略为MustRunAs。准入控制会查找openshift.io/sa.scc.supplemental-groups注释。 -
SupplementalGroups策略为MustRunAs。准入控制会查找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 Container Platform 才会接受请求特定用户 ID 的容器或 Pod。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 的组。 |
|
为了在升级期间保留自定义 SCC，请不要编辑默认 SCC 上的设置。 |