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

配置 seccomp 配置文件

OpenShift Container Platform 容器或 Pod 运行单个应用程序，该应用程序执行一个或多个定义明确的任务。应用程序通常只需要底层操作系统内核 API 的一小部分。安全计算模式 seccomp 是 Linux 内核的一项功能，可用于限制在容器中运行的进程仅使用可用的系统调用的子集。

restricted-v2 SCC 应用于 4.17 中所有新创建的 Pod。默认 seccomp 配置文件 runtime/default 应用于这些 Pod。

Seccomp 配置文件存储为磁盘上的 JSON 文件。

Seccomp 配置文件不能应用于特权容器。

验证应用于 Pod 的默认 seccomp 配置文件

OpenShift Container Platform 附带一个默认的 seccomp 配置文件，其引用为 runtime/default。在 4.17 中，新创建的 Pod 的安全上下文约束 (SCC) 设置为 restricted-v2，并且默认 seccomp 配置文件应用于该 Pod。

步骤

  1. 您可以通过运行以下命令来验证 Pod 上设置的安全上下文约束 (SCC) 和默认 seccomp 配置文件

    1. 验证命名空间中正在运行哪些 Pod

      $ oc get pods -n <namespace>

      例如，要验证 workshop 命名空间中正在运行哪些 Pod，请运行以下命令：

      $ oc get pods -n workshop
      示例输出
      NAME                READY   STATUS      RESTARTS   AGE
parksmap-1-4xkwf    1/1     Running     0          2m17s
parksmap-1-deploy   0/1     Completed   0          2m22s

    2. 检查 Pod

      $ oc get pod parksmap-1-4xkwf -n workshop -o yaml
      示例输出
      apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "ovn-kubernetes",
          "interface": "eth0",
          "ips": [
              "10.131.0.18"
          ],
          "default": true,
          "dns": {}
      }]
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "ovn-kubernetes",
          "interface": "eth0",
          "ips": [
              "10.131.0.18"
          ],
          "default": true,
          "dns": {}
      }]
    openshift.io/deployment-config.latest-version: "1"
    openshift.io/deployment-config.name: parksmap
    openshift.io/deployment.name: parksmap-1
    openshift.io/generated-by: OpenShiftWebConsole
    openshift.io/scc: restricted-v2 (1)
    seccomp.security.alpha.kubernetes.io/pod: runtime/default (2)
      1 如果您的工作负载无法访问其他 SCC，则默认情况下会添加 restricted-v2 SCC。
      2 4.17 中新创建的 Pod 将根据 SCC 的规定将 seccomp 配置文件配置为 runtime/default。

升级后的集群

在升级到 4.17 的集群中，所有经过身份验证的用户都可以访问 restricted 和 restricted-v2 SCC。

例如，在 OpenShift Container Platform v4.10 集群升级时，由 SCC restricted 承认的工作负载可能会被 restricted-v2 承认。这是因为 restricted-v2 是 restricted 和 restricted-v2 之间更严格的 SCC。

工作负载必须能够使用 restricted-v2 运行。

相反，对于需要privilegeEscalation: true的工作负载，任何已认证的用户仍然可以使用restricted SCC。这是因为restricted-v2不允许privilegeEscalation。

新安装的集群

对于新安装的OpenShift Container Platform 4.11或更高版本的集群，restricted-v2取代了restricted SCC，成为任何已认证用户都可以使用的SCC。由于restricted-v2是默认情况下已认证用户唯一可用的SCC，因此privilegeEscalation: true的工作负载无法进入集群。

restricted允许privilegeEscalation功能，但restricted-v2不允许。restricted-v2拒绝的功能比restricted SCC允许的功能更多。

privilegeEscalation: true的工作负载可能被允许进入新安装的OpenShift Container Platform 4.11或更高版本的集群。要将对restricted SCC的访问权限授予运行该工作负载的服务帐户（或任何其他可以接纳此工作负载的SCC），请使用RoleBinding运行以下命令。

$ oc -n <workload-namespace> adm policy add-scc-to-user <scc-name> -z <serviceaccount_name>

在OpenShift Container Platform 4.17中，添加pod注释seccomp.security.alpha.kubernetes.io/pod: runtime/default和container.seccomp.security.alpha.kubernetes.io/: runtime/default的功能已弃用。

配置自定义seccomp配置文件

您可以配置自定义seccomp配置文件，这允许您根据应用程序需求更新过滤器。这允许集群管理员更好地控制在OpenShift Container Platform中运行的工作负载的安全性。

Seccomp安全配置文件列出了进程可以执行的系统调用（syscall）。其权限比SELinux更宽松，SELinux限制系统范围的操作，例如write。

创建seccomp配置文件

您可以使用MachineConfig对象来创建配置文件。

Seccomp可以限制容器内的系统调用（syscall），从而限制应用程序的访问权限。

先决条件

  • 您拥有集群管理员权限。

  • 您已创建自定义安全上下文约束 (SCC)。有关更多信息，请参见“其他资源”。

步骤

  • 创建MachineConfig对象

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: custom-seccomp
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,<hash>
        filesystem: root
        mode: 0644
        path: /var/lib/kubelet/seccomp/seccomp-nostat.json

设置自定义seccomp配置文件

先决条件

  • 您拥有集群管理员权限。

  • 您已创建自定义安全上下文约束 (SCC)。有关更多信息，请参见“其他资源”。

  • 您已创建自定义seccomp配置文件。

步骤

  1. 使用Machine Config将您的自定义seccomp配置文件上传到/var/lib/kubelet/seccomp/.json。有关详细步骤，请参见“其他资源”。

  2. 通过提供对已创建的自定义seccomp配置文件的引用来更新自定义SCC。

    seccompProfiles:
- localhost/<custom-name>.json (1)
    1 提供您的自定义seccomp配置文件的名称。

将自定义seccomp配置文件应用于工作负载

先决条件

  • 集群管理员已设置自定义seccomp配置文件。有关更多详细信息，请参见“设置自定义seccomp配置文件”。

步骤

  • 通过设置securityContext.seccompProfile.type字段来将seccomp配置文件应用于工作负载，如下所示：

    示例
    spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: <custom-name>.json (1)
    1 提供您的自定义seccomp配置文件的名称。

    或者，您可以使用pod注释seccomp.security.alpha.kubernetes.io/pod: localhost/.json。但是，此方法在OpenShift Container Platform 4.17中已弃用。

在部署过程中，准入控制器将验证以下内容：

  • 针对用户角色允许的当前SCC的注释。

  • 允许pod使用的SCC（包括seccomp配置文件）。

如果允许pod使用SCC，则kubelet将使用指定的seccomp配置文件运行pod。

确保seccomp配置文件已部署到所有工作节点。

自定义SCC必须具有适当的优先级才能自动分配给pod，或者满足pod所需的其它条件，例如允许CAP_NET_ADMIN。

其他资源