GKE 中的 seccomp 简介

本页面介绍 Google Kubernetes Engine (GKE) 中的 Linux“安全计算”模式 (seccomp)。使用此信息您可以了解容器化应用可以在托管节点的主机虚拟机上执行哪些操作。

本页面适用于将 seccomp 作为其组织安全策略一部分，并希望了解 GKE 如何与 seccomp 配置文件进行交互的安全专家。如需详细了解我们在 Trusted Cloud by S3NS 内容中提及的常见角色和示例任务，请参阅常见的 GKE Enterprise 用户角色和任务。

seccomp 是什么？

安全计算模式 (seccomp) 是 Linux 中的一项安全功能，可让您限制进程可对 Linux 内核进行的系统调用 (syscall)。

默认情况下，GKE 节点使用 Container-Optimized OS 操作系统和 containerd 容器运行时。containerd 通过仅允许使用默认列表中列出的 Linux 功能来保护 Linux 内核，还可以通过 seccomp 配置文件进一步限制允许的系统调用。containerd 具有可用的默认 seccomp 配置文件。GKE 是否会为您应用默认 seccomp 配置文件取决于您使用的集群模式，如下所示：

  • Autopilot（推荐）：GKE 会自动将 containerd 默认 seccomp 配置文件应用于所有工作负载。
  • 标准：GKE 不会自动将 containerd 默认 seccomp 配置文件应用于所有工作负载。我们建议您将默认 seccomp 配置文件或自定义 seccomp 配置文件应用于您的工作负载。

默认的 containerd seccomp 配置文件可提供基准安全强化功能，同时保持与大多数工作负载兼容。GitHub 上提供了 containerd 的完整 seccomp 配置文件定义。

Linux 功能和系统调用

在 Linux 系统上运行的非根进程可能需要特定权限才能以根用户身份执行操作。Linux 使用“功能”将可用权限划分为多个组，以便非根进程可以在未被授予所有权限的情况下执行特定操作。要使进程成功执行特定的系统调用，该进程必须具有通过功能授予的相应权限。

如需查看所有 Linux 功能的列表，请参阅功能。

默认 GKE seccomp 配置文件中的遭拒系统调用

containerd 默认 seccomp 配置文件会阻止所有系统调用，然后有选择性地允许特定的系统调用，部分取决于节点虚拟机的 CPU 架构和内核版本。DefaultProfile 函数中的 syscalls 变量列出了所有架构允许的系统调用。

默认的 seccomp 配置文件会阻止可用于绕过容器隔离边界并允许对节点或其他容器进行特权访问的系统调用。下表介绍了默认 seccomp 配置文件拒绝的一些重要系统调用：

遭拒的系统调用
mount、umount、umount2、fsmount、mount_setattr

阻止进程在容器边界之外访问或操控节点文件系统。

也因为 CAP_SYS_ADMIN 功能被停用而遭拒。
bpf

阻止进程在内核中创建 eBPF 程序，因为这可能会导致节点上出现提权现象。例如，CVE-2021-3490 使用了 bpf 系统调用。 也因为 CAP_SYS_ADMIN 功能被停用而遭拒。
clone、clone3、unshare

阻止进程在可能位于容器受限命名空间之外的新命名空间中创建新进程。这些新进程可能具有提升的权限和功能。例如，CVE-2022-0185 使用了 unshare 系统调用。 也因为 CAP_SYS_ADMIN 功能被停用而遭拒。
reboot

阻止进程重新启动节点。

因为 CAP_SYS_BOOT 功能被停用而遭拒。
open_by_handle_at、name_to_handle_at

阻止对容器外部的文件的访问。这些系统调用出现在最早的 Docker 容器逃逸漏洞中。也因为 CAP_DAC_READ_SEARCH 功能和 CAP_SYS_ADMIN 功能被停用而遭拒。

如何在 GKE 中使用 seccomp

在 Autopilot 集群中，GKE 会自动将 containerd 默认 seccomp 配置文件应用于所有工作负载。您无需执行进一步操作。尝试进行受限系统调用的操作会失败。Autopilot 不允许自定义 seccomp 配置文件，因为 GKE 会管理节点。

在标准集群中，您必须手动应用 seccomp 配置文件；GKE 不会为您应用配置文件。

在标准集群中启用 seccomp

使用 Pod 规范中的 spec.securityContext.seccompProfile 字段设置 Pod 或容器的安全上下文，以手动应用 seccomp 配置文件，如以下示例所示。除非您的使用场景需要使用任何受限的系统调用，否则我们强烈建议您为工作负载使用 seccomp 配置文件。两种受支持的 seccompProfile 类型如下所示：

以下示例清单将 seccomp 配置文件设置为运行时默认配置文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: default-pod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: default-pod
  template:
    metadata:
      labels:
        app: default-pod
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: seccomp-test
        image: nginx

部署此清单时，如果 Pod 中的容器尝试进行违反运行时默认 seccomp 配置文件的系统调用，则 Pod 或工作负载可能会出现意外行为。例如，在启动期间进行受限系统调用的 Pod 将无法启动。如果应用尝试在 Pod 运行时进行受限的系统调用，容器中可能会出现错误。系统调用失败的严重级别取决于应用处理错误的方式。

在标准集群中使用自定义 seccomp 配置文件

如果运行时默认 seccomp 配置文件对您的应用来说限制过于严格（或限制不够），您可以将自定义 seccomp 配置文件应用于标准集群中的 Pod。此过程需要访问节点上的文件系统。有关如何加载和使用自定义 seccomp 配置文件的教程，请参阅使用 seccomp 限制容器的系统调用。

后续步骤