符合 Pod 安全准入 - 开发 Operators | Operators | Red Hat OpenShift Service on AWS

关于 Pod 安全准入
关于 Pod 安全准入同步
- Pod 安全准入同步命名空间排除
确保 Operator 工作负载在设置为受限 Pod 安全级别的命名空间中运行
管理需要提升权限的 Operator 工作负载的 Pod 安全准入
其他资源

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

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

Operator 命名空间允许的 Pod 安全准入级别
工作负载的服务帐户允许的安全上下文约束 (SCC)

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

不建议使用 Red Hat 支持的 Operator SDK 版本创建新的 Operator 项目。拥有现有 Operator 项目的 Operator 作者可以使用随 Red Hat OpenShift Service on AWS 发布的 Operator SDK CLI 工具版本来维护其项目并创建针对较新版本的 Red Hat OpenShift Service on AWS 的 Operator 版本。

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

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

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

关于 Pod 安全准入

Red Hat OpenShift Service on AWS 包括 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 安全准入同步命名空间排除

系统创建的命名空间和以 `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 配置文件。但是，在 Red Hat OpenShift Service on AWS 4.10 中不支持设置 seccomp 配置文件。
- 对于必须仅在 Red Hat OpenShift Service on AWS 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 安全配置文件。
- 对于还必须在 Red Hat OpenShift Service on AWS 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 项目可以在 Red Hat OpenShift Service on AWS 4.10 中运行。

其他资源

管理安全上下文约束

编辑

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

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

步骤

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

具有网络管理员权限的示例 `.clusterserviceversion.yaml` 文件

...
containers:
   - name: my-container
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         add:
           - "NET_ADMIN"
...

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

示例 `.clusterserviceversion.yaml` 文件

...
  install:
    spec:
      clusterPermissions:
      - rules:
        - apiGroups:
          - security.openshift.io
          resourceNames:
          - privileged
          resources:
          - securitycontextconstraints
          verbs:
          - use
        serviceAccountName: default
...

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

示例 `.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.

编辑

其他资源

了解和管理 Pod 安全准入