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

符合 Pod 安全准入

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

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

  • 操作符命名空间允许的 Pod 安全准入级别

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

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

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

不建议使用 Red Hat 支持的 Operator SDK 版本创建新的 Operator 项目。拥有现有 Operator 项目的操作符作者可以使用 OpenShift Dedicated 发布的 Operator SDK CLI 工具版本来维护他们的项目并创建针对较新版本的 OpenShift Dedicated 的 Operator 版本。

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

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

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

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

关于 Pod 安全准入

OpenShift Dedicated 包含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 安全准入模式
模式 标签 描述

强制执行

pod-security.kubernetes.io/enforce

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

审计

pod-security.kubernetes.io/audit

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

警告

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 安全准入同步命名空间排除

系统创建的命名空间和以openshift-*为前缀的命名空间永久禁用 Pod 安全准入同步。

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

  • default

  • kube-node-lease

  • kube-system

  • kube-public

  • openshift

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

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

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

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

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

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

    • 对于必须仅在 OpenShift Dedicated 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 Dedicated 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 Dedicated 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.

其他资源