使用 OCI 工件分发 seccomp、SELinux 和 AppArmor 的安全配置文件

安全配置文件操作符 (SPO) 使在 Kubernetes 中管理 seccomp、SELinux 和 AppArmor 配置文件比以往任何时候都更容易。它允许集群管理员在预定义的自定义资源 YAML 中定义配置文件，然后由 SPO 将其分发到整个集群中。安全配置文件的修改和删除也由操作符以相同的方式管理，但这只是其功能的一小部分。

SPO 的另一个核心功能是能够堆叠 seccomp 配置文件。这意味着用户可以在 YAML 规范中定义一个 baseProfileName，然后操作符会自动解析它并组合 syscall 规则。如果基本配置文件有另一个 baseProfileName，那么操作符将递归解析配置文件到一定深度。一个常见的用例是为底层容器运行时（如 runc 或 crun）定义基本配置文件，其中包含在任何情况下运行容器所需的系统调用。或者，应用程序开发人员可以为其标准发行版容器定义 seccomp 基本配置文件，并在其之上堆叠用于应用程序逻辑的专用配置文件。这样，开发人员可以专注于维护更简单且范围限定于应用程序逻辑的 seccomp 配置文件，而无需考虑整个基础设施设置。

但是如何维护这些基本配置文件呢？例如，运行时的所需系统调用数量可能会在其发布周期内发生变化，就像主应用程序一样。基本配置文件必须在同一集群中可用，否则主 seccomp 配置文件将无法部署。这意味着它们与主应用程序配置文件紧密耦合，这与基本配置文件的主要思想背道而驰。将它们作为普通文件分发和管理感觉是需要解决的额外负担。

OCI 工件来救援

安全配置文件操作符的 v0.8.0 版本支持将基本配置文件作为 OCI 工件进行管理！将 OCI 工件想象为轻量级容器镜像，以与镜像相同的方式在层中存储文件，但没有要执行的进程。这些工件可以像常规容器镜像一样在兼容的注册表中存储安全配置文件。这意味着它们可以像常规容器镜像一样进行版本控制、命名空间化和注释。

要了解其工作原理，请在 seccomp 配置文件 CRD 中指定一个以 oci:// 为前缀的 baseProfileName，例如

apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  name: test
spec:
  defaultAction: SCMP_ACT_ERRNO
  baseProfileName: oci://ghcr.io/security-profiles/runc:v1.1.5
  syscalls:
    - action: SCMP_ACT_ALLOW
      names:
        - uname

操作符将负责使用 oras 拉取内容，以及验证工件的 sigstore (cosign) 签名。如果工件未签名，则 SPO 将拒绝它们。生成的配置文件 test 将包含远程 runc 配置文件中的所有基本系统调用以及附加允许的 uname 系统调用。也可以通过其摘要 (SHA256) 引用基本配置文件，使要拉取的工件更加具体，例如通过引用 oci://ghcr.io/security-profiles/runc@sha256:380…。

操作符在内部缓存拉取的工件最多 24 小时，最多 1000 个配置文件，这意味着它们将在该时间段后刷新，如果缓存已满或操作符守护进程重新启动。

因为整体生成的系统调用对用户是隐藏的（我只在 SeccompProfile 中列出了 baseProfileName，而不是系统调用本身），我还将使用最终的 syscalls 来注释该 SeccompProfile。

这是我在注释后 SeccompProfile 的外观

> kubectl describe seccompprofile test
Name:         test
Namespace:    security-profiles-operator
Labels:       spo.x-k8s.io/profile-id=SeccompProfile-test
Annotations:  syscalls:
                [{"names":["arch_prctl","brk","capget","capset","chdir","clone","close",...
API Version:  security-profiles-operator.x-k8s.io/v1beta1

SPO 维护人员在 “安全配置文件” GitHub 组织中提供所有公共基本配置文件。

管理 OCI 安全配置文件

好的，现在官方的 SPO 提供了一堆基本配置文件，但是如何定义我自己的配置文件呢？首先，我们必须选择一个可用的注册表。已经有很多注册表支持 OCI 工件

• CNCF 分发
• Azure 容器注册表
• Amazon Elastic Container Registry
• Google Artifact Registry
• GitHub Packages 容器注册表
• Docker Hub
• Zot 注册表

安全配置文件操作符附带一个名为 spoc 的新命令行界面，这是一个用于管理 OCI 配置文件的辅助工具，以及执行本博客文章范围之外的各种其他事情。但是，命令 spoc push 可用于将安全配置文件推送到注册表

> export USERNAME=my-user
> export PASSWORD=my-pass
> spoc push -f ./examples/baseprofile-crun.yaml ghcr.io/security-profiles/crun:v1.8.3
16:35:43.899886 Pushing profile ./examples/baseprofile-crun.yaml to: ghcr.io/security-profiles/crun:v1.8.3
16:35:43.899939 Creating file store in: /tmp/push-3618165827
16:35:43.899947 Adding profile to store: ./examples/baseprofile-crun.yaml
16:35:43.900061 Packing files
16:35:43.900282 Verifying reference: ghcr.io/security-profiles/crun:v1.8.3
16:35:43.900310 Using tag: v1.8.3
16:35:43.900313 Creating repository for ghcr.io/security-profiles/crun
16:35:43.900319 Using username and password
16:35:43.900321 Copying profile to repository
16:35:46.976108 Signing container image
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.

By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs.
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=…
Successfully verified SCT...
tlog entry created with index: 16520520
Pushing signature to: ghcr.io/security-profiles/crun

你可以看到该工具会自动签名工件并将 ./examples/baseprofile-crun.yaml 推送到注册表，然后该注册表就可以直接在 SPO 中使用。如果需要用户名和密码身份验证，请使用 --username、-u 标志或导出 USERNAME 环境变量。要设置密码，请导出 PASSWORD 环境变量。

可以通过在 KEY:VALUE 格式中多次使用 --annotations / -a 标志，将自定义注释添加到安全配置文件。这些注释目前没有效果，但在稍后的某个时间点，操作符的其他功能可能会依赖它们。

spoc 客户端还能够从 OCI 工件兼容的注册表中拉取安全配置文件。要执行此操作，只需运行 spoc pull

> spoc pull ghcr.io/security-profiles/runc:v1.1.5
16:32:29.795597 Pulling profile from: ghcr.io/security-profiles/runc:v1.1.5
16:32:29.795610 Verifying signature

Verification for ghcr.io/security-profiles/runc:v1.1.5 --
The following checks were performed on each of these signatures:
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

[{"critical":{"identity":{"docker-reference":"ghcr.io/security-profiles/runc"},…}}]
16:32:33.208695 Creating file store in: /tmp/pull-3199397214
16:32:33.208713 Verifying reference: ghcr.io/security-profiles/runc:v1.1.5
16:32:33.208718 Creating repository for ghcr.io/security-profiles/runc
16:32:33.208742 Using tag: v1.1.5
16:32:33.208743 Copying profile from repository
16:32:34.119652 Reading profile
16:32:34.119677 Trying to unmarshal seccomp profile
16:32:34.120114 Got SeccompProfile: runc-v1.1.5
16:32:34.120119 Saving profile in: /tmp/profile.yaml

现在可以在 /tmp/profile.yaml 或指定的输出文件 --output-file / -o 中找到该配置文件。我们可以使用与 spoc push 相同的方式指定用户名和密码。

spoc 使将安全配置文件作为 OCI 工件进行管理变得容易，然后可以直接由操作符本身使用。

这就是我们对安全配置文件操作符最新可能性的简短旅程！如果您对更多信息感兴趣、提供反馈或寻求帮助，请随时通过 Slack (#security-profiles-operator) 或 邮件列表 直接与我们联系。

• ←上一篇
下一篇→