OpenShift 文档正在迁移，很快将只能在 docs.redhat.com（所有 Red Hat 产品文档的中心）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

符合 Pod 安全准入

Pod安全准入是Kubernetes Pod安全标准的实现。Pod安全准入限制Pod的行为。不符合全局或命名空间级别定义的Pod安全准入的Pod不会被接纳到集群中，也不能运行。

如果您的Operator项目不需要提升权限即可运行，您可以确保您的工作负载在设置为restricted Pod安全级别的命名空间中运行。如果您的Operator项目需要提升权限才能运行，则必须设置以下安全上下文配置

  • Operator命名空间允许的Pod安全准入级别

  • 工作负载的服务帐户允许的安全上下文约束 (SCC)

更多信息，请参见了解和管理Pod安全准入。

Red Hat支持的Operator SDK CLI工具版本（包括与Operator项目相关的脚手架和测试工具）已弃用，并计划在未来版本的OpenShift Container Platform中移除。Red Hat将在当前发布生命周期内为此功能提供错误修复和支持，但此功能将不再接收增强功能，并将从未来的OpenShift Container Platform版本中移除。

不建议使用Red Hat支持的Operator SDK版本创建新的Operator项目。拥有现有Operator项目的Operator作者可以使用OpenShift Container Platform 4.17随附的Operator SDK CLI工具版本来维护其项目并创建面向更新版本的OpenShift Container Platform的Operator版本。

以下与Operator项目相关的基础镜像未被弃用。这些基础镜像的运行时功能和配置API仍然支持错误修复和解决CVE。

  • 基于Ansible的Operator项目的基镜像

  • 基于Helm的Operator项目的基镜像

有关OpenShift Container Platform中已弃用或移除的主要功能的最新列表，请参阅OpenShift Container Platform发行说明中的“已弃用和移除的功能”部分。

有关不受支持的社区维护版本的Operator SDK的信息，请参见Operator SDK (Operator Framework)。

关于Pod安全准入

OpenShift Container Platform包含Kubernetes Pod安全准入。不符合全局或命名空间级别定义的Pod安全准入的Pod不会被接纳到集群中，也不能运行。

在全局范围内，强制执行privileged配置文件，并使用restricted配置文件进行警告和审计。

您也可以在命名空间级别配置Pod安全准入设置。

不要在默认项目中运行工作负载或共享对默认项目的访问权限。默认项目保留用于运行核心集群组件。

以下默认项目被视为高度特权项目：default、kube-public、kube-system、openshift、openshift-infra、openshift-node，以及其他设置了openshift.io/run-level标签为0或1的系统创建项目。依赖于准入插件的功能，例如 Pod 安全准入、安全上下文约束、集群资源配额和镜像引用解析，在高度特权项目中不起作用。

Pod 安全准入模式

您可以为命名空间配置以下 Pod 安全准入模式

表 1. Pod 安全准入模式
模式 标签 描述

enforce

pod-security.kubernetes.io/enforce

如果 Pod 不符合设定的配置文件，则拒绝 Pod 准入。

audit

pod-security.kubernetes.io/audit

如果 Pod 不符合设定的配置文件，则记录审计事件。

warn

pod-security.kubernetes.io/warn

如果 Pod 不符合设定的配置文件，则显示警告。

Pod 安全准入配置文件

您可以将每种 Pod 安全准入模式设置为以下配置文件之一

表 2. Pod 安全准入配置文件
配置文件 描述

privileged

限制最少的策略；允许已知的权限提升。

baseline

限制最小的策略；防止已知的权限提升。

restricted

限制最严格的策略；遵循当前的 Pod 加固最佳实践。

特权命名空间

以下系统命名空间始终设置为privileged Pod 安全准入配置文件

  • default

  • kube-public

  • kube-system

您无法更改这些特权命名空间的 Pod 安全配置文件。

关于 Pod 安全准入同步

除了全局 Pod 安全准入控制配置之外，控制器还会根据给定命名空间中服务帐户的 SCC 权限，将 Pod 安全准入控制warn和audit标签应用于命名空间。

控制器检查ServiceAccount对象的权限，以便在每个命名空间中使用安全上下文约束。安全上下文约束 (SCC) 基于其字段值映射到 Pod 安全配置文件；控制器使用这些转换后的配置文件。Pod 安全准入warn和audit标签设置为命名空间中权限最高的 Pod 安全配置文件，以防止在创建 Pod 时显示警告和记录审计事件。

命名空间标记基于对命名空间本地服务帐户权限的考虑。

直接应用 Pod 可能会使用运行 Pod 的用户的 SCC 权限。但是，在自动标记期间不考虑用户权限。

Pod 安全准入同步命名空间排除

大多数系统创建的命名空间都永久禁用了 Pod 安全准入同步。用户创建的以openshift-*为前缀的命名空间也最初禁用了同步，但您可以稍后在这些命名空间上启用同步。

如果 Pod 安全准入标签 (pod-security.kubernetes.io/<mode>) 从已自动标记的标签同步命名空间上的自动标记值手动修改，则该标签的同步将被禁用。

如有必要，您可以使用以下方法之一重新启用同步

  • 从命名空间中删除已修改的 Pod 安全准入标签

  • 将security.openshift.io/scc.podSecurityLabelSync标签设置为true

    如果您通过添加此标签强制同步，则任何已修改的 Pod 安全准入标签都将被覆盖。

永久禁用的命名空间

作为集群有效负载一部分定义的命名空间永久禁用了 Pod 安全准入同步。以下命名空间永久禁用：

  • default

  • kube-node-lease

  • kube-system

  • kube-public

  • openshift

  • 所有以openshift-为前缀的系统创建的命名空间，除了openshift-operators

最初禁用的命名空间

默认情况下，所有以openshift-为前缀的命名空间最初都禁用了 Pod 安全准入同步。您可以为用户创建的openshift-*命名空间和openshift-operators命名空间启用同步。

您无法为任何系统创建的openshift-*命名空间启用同步，openshift-operators除外。

如果在用户创建的openshift-*命名空间中安装了 Operator，则在命名空间中创建集群服务版本 (CSV) 后，将自动启用同步。同步的标签源自命名空间中服务帐户的权限。

确保 Operator 工作负载在设置为受限 Pod 安全级别的命名空间中运行

为了确保您的 Operator 项目可以在各种部署和环境中运行，请将 Operator 的工作负载配置为在设置为restricted Pod 安全级别的命名空间中运行。

您必须将runAsUser字段留空。如果您的镜像需要特定用户，则它不能在受限安全上下文约束 (SCC) 和受限 Pod 安全强制下运行。
步骤

  • 要将 Operator 工作负载配置为在设置为restricted Pod 安全级别的命名空间中运行，请编辑您的 Operator 的命名空间定义，类似于以下示例

    建议您在 Operator 的命名空间定义中设置 seccomp 配置文件。但是，在 OpenShift Container Platform 4.10 中不支持设置 seccomp 配置文件。

    • 对于必须仅在 OpenShift Container Platform 4.11 及更高版本中运行的 Operator 项目，请编辑您的 Operator 的命名空间定义，类似于以下示例

      示例config/manager/manager.yaml文件
      ...
spec:
 securityContext:
   seccompProfile:
     type: RuntimeDefault (1)
   runAsNonRoot: true
 containers:
   - name: <operator_workload_container>
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         drop:
           - ALL
...
      1 通过将 seccomp 配置文件类型设置为RuntimeDefault，SCC 将默认为命名空间的 Pod 安全配置文件。

    • 对于也必须在 OpenShift Container Platform 4.10 中运行的 Operator 项目，请编辑您的 Operator 的命名空间定义，类似于以下示例

      示例config/manager/manager.yaml文件
      ...
spec:
 securityContext: (1)
   runAsNonRoot: true
 containers:
   - name: <operator_workload_container>
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         drop:
           - ALL
...
      1 将 seccomp 配置文件类型留空可确保您的 Operator 项目可以在 OpenShift Container Platform 4.10 中运行。
其他资源

管理需要提升权限的 Operator 工作负载的 Pod 安全准入

如果您的 Operator 项目需要提升权限才能运行，则必须编辑您的 Operator 的集群服务版本 (CSV)。

步骤

  1. 在您的 Operator 的 CSV 中将安全上下文配置设置为所需的权限级别，类似于以下示例

    具有网络管理员权限的示例<operator_name>.clusterserviceversion.yaml文件
    ...
containers:
   - name: my-container
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         add:
           - "NET_ADMIN"
...

  2. 设置允许您的 Operator 的工作负载使用所需安全上下文约束 (SCC) 的服务帐户权限，类似于以下示例

    示例<operator_name>.clusterserviceversion.yaml文件
    ...
  install:
    spec:
      clusterPermissions:
      - rules:
        - apiGroups:
          - security.openshift.io
          resourceNames:
          - privileged
          resources:
          - securitycontextconstraints
          verbs:
          - use
        serviceAccountName: default
...

  3. 编辑您的 Operator 的 CSV 说明以解释您的 Operator 项目为什么需要提升的权限，类似于以下示例

    示例<operator_name>.clusterserviceversion.yaml文件
    ...
spec:
  apiservicedefinitions:{}
  ...
description: The <operator_name> requires a privileged pod security admission label set on the Operator's namespace. The Operator's agents require escalated permissions to restart the node if the node needs remediation.

其他资源