IBM Cloud Docs
配置安全上下文约束

配置安全上下文约束

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