配置安全上下文约束

通过安全上下文约束 (SCC)，可以控制 Red Hat® OpenShift® on IBM Cloud® 集群中 pod 可以执行的操作和具有的访问权。有关SCCs的更多信息，请参阅文档 Red Hat OpenShift。

为什么要设置安全上下文约束？: 作为集群管理员，您会希望控制集群中发生的任何情况，尤其是影响集群安全性或就绪性的操作。安全上下文约束可以帮助控制容器中的 pod 可执行的操作和具有的访问权，例如，如何使用特权容器、根名称空间、主机联网和端口、卷类型、主机文件系统、Linux 许可权（如只读）或组标识等。
我还可以将用户或系统组添加到 SCC 吗?: 对于用户对集群资源的访问权，请勿使用 SCC。请改为参阅分配集群访问权以设置 IBM Cloud IAM 和基础架构许可权。; 对于 system:authenticated 之类的系统组，这些组已分配给 SCC。您可以通过描述 SCC 来查看将哪些组分配给 SCC。如果更改将系统组分配到的 SCC，那么属于该系统组的缺省组件可能会因许可权更改而迂到错误。
默认情况下是否设置了任何SCC？: 默认情况下，Red Hat OpenShift on IBM Cloud 集群包括一组标准的 Red Hat OpenShift SCC。此外，集群中的 IBM 安全控制项（SCC）与 IBM Cloud Kubernetes Service 中社区版 Kubernetes 集群的 Kubernetes Pod安全策略非常相似。包含这些 IBM SCC 是为了提高 IBM Cloud Private 包（例如，Cloud Pak）的可移植性。
我的资源默认应用了哪些SCC？: 如果未指定安全上下文，那么缺省情况下将应用 Red Hat OpenShift restricted (或 4.11 及更高版本中的 restricted-v2 ) 安全上下文约束。要检查 pod 的安全上下文，请描述此 pod 并查找 SCC 注释，如以下示例所示。

oc describe pod <pod_name>

Name:               <pod_name>
Namespace:          <project_name>
...
Annotations:        openshift.io/...
                    openshift.io/scc=restricted
...

我能否改用 Kubernetes 的Pod安全策略？: 编号 Kubernetes pod 安全策略 (PSP) 最初基于 Red Hat OpenShift SCC。不过，Red Hat OpenShift 仅支持 SCC，不支持 PSP。

Red Hat OpenShift 的默认SCC比社区版 Kubernetes 集群中的默认PSP更为严格。因此，在社区版 Kubernetes 集群中运行的应用程序部署可能需要进行修改，以便在 Red Hat OpenShift 中运行。

定制安全上下文约束

要创建、编辑、列出、删除以及管理安全上下文约束，请参阅 Red Hat OpenShift 文档。您还可以使用基于角色的访问控制 (例如 clusterroles，clusterrolebindings，roles 和 rolebindings) 来授权用户或组使用缺省安全上下文约束。您还可以使用 oc adm policy 子命令 (例如 oc adm policy add-scc-to-user) 来管理这些设置。 Oc 版本与受管集群的版本相同。

分配 SCC 访问权的准则

将特定服务帐户授权给要由在该服务帐户下运行的 Pod 使用的 SCC。
如果服务帐户需要访问多个 SCC，请考虑创建其他服务帐户，以便期望在服务帐户下运行的所有 pod 都使用相同的 SCC。
请勿授权所有用户或所有服务帐户使用除 restricted (4.10 和更低版本) 或 restricted-v2 (4.11 和更高版本) SCC 以外的任何 SCC。
请勿更改 openshift-* 名称空间中服务帐户的 SCC 授权。Red Hat OpenShift 组件设计为在特定 SCC 下运行，并且可能无法在其他 SCC 下正常运行。

缺省的 Red Hat OpenShift 安全上下文约束

Red Hat OpenShift on IBM Cloud 集群默认具有以下安全上下文约束。

请勿编辑现有的 Red Hat OpenShift 或 IBM SCC 设置，但 priority、users 或 groups 字段除外。

缺省 Red Hat OpenShift 安全上下文约束
SCC 名称	描述
`anyuid`	拒绝访问，类似于 `restricted` SCC，但允许用户使用任何 UID 和任何 GID 来运行。
`hostaccess`	允许访问所有主机名称空间，但仍需要使用分配给名称空间的 UID 和 SELinux 上下文来运行 pod。重要提示：仅应向需要访问命名空间、文件系统和进程 ID 的受信任 Pod 授予此 SCC。
`hostmount-anyuid`	拒绝访问，类似于 `restricted` SCC，但允许 pod 进行主机安装以及使用任何 UID。此 SCC 主要由持久卷回收器使用。重要提示：仅应向需要以任意 UID（包括 UID 0）访问主机文件系统的 Pod 授予此 SCC。
`hostnetwork`	允许使用主机联网和主机端口，但仍需要使用分配给名称空间的 UID 和 SELinux 上下文来运行 pod。重要提示：仅向需要访问主机网络的 Pod 授予此 SCC。
`node-exporter`	为内置 Prometheus 节点导出器授予相应的访问权。
`nonroot`	拒绝访问，类似于 `restricted` SCC，但允许用户使用任何非根 UID 运行。容器运行时的用户或清单必须指定 UID。
`privileged`	允许访问所有特权功能和主机功能，并能够以任何用户、任何组、任何 `fsGroup` 设置以及任何SELinux上下文的身份运行。重要提示：仅在需要最大访问权限的集群管理场景下授予此 SCC。
`restricted`	拒绝访问所有主机功能，并且需要使用分配给名称空间的 UID 和 SELinux 上下文来运行 pod。这是最严格的 SCC，缺省情况下用于已认证的用户。
`hostnetwork-v2`	类似于 `hostnetwork` SCC，但已修改以最小化 Pod 安全标准 `Restricted` 概要文件的差异。
`nonroot-v2`	类似于 `nonroot` SCC，但已修改以最小化 Pod 安全标准 `Restricted` 概要文件的差异。
`restricted-v2`	类似于 `restricted` SCC，但已修改为满足 Pod 安全标准 `Restricted` 概要文件。

缺省 IBM 安全上下文约束

Red Hat OpenShift on IBM Cloud 集群默认具有以下 IBM 安全上下文约束。

请勿编辑现有的 Red Hat OpenShift 或 IBM SCC 设置，但 priority、users 或 groups 字段除外。

缺省 IBM 安全上下文约束
SCC 名称	描述
`ibm-anyuid-hostaccess-scc`	允许 pod 使用任何 UID 和 GID 运行、运行任何卷以及具有对主机的完全访问权。重要提示：仅应向需要完全访问主机和网络的 Pod 授予此 SCC。
`ibm-anyuid-hostpath-scc`	允许 pod 使用任何 UID 和 GID 运行以及运行任何卷，包括主机路径。重要提示：仅向需要访问 `hostPath` 卷的Pod授予此SCC。
`ibm-anyuid-scc`	允许 pod 使用任何 UID 和 GID 运行，但阻止访问主机。
`ibm-privileged-scc`	授予对所有特权主机功能的访问权，并允许 pod 使用任何 UID 和 GID 运行以及运行任何卷。重要提示：仅在需要最大访问权限的集群管理场景下授予此 SCC。
`ibm-restricted-scc`	拒绝访问所有主机功能，并且需要使用分配给名称空间的 UID 和 SELinux 上下文来运行 pod。此 SCC 是限制最严格的 IBM SCC。