本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Security Profiles Operator v0.4.0 的新功能
Security Profiles Operator (SPO) 是一个开箱即用的 Kubernetes 增强功能，旨在使 seccomp、SELinux 和 AppArmor 配置文件的管理变得更加简单和方便。我们很高兴地宣布，我们最近 发布了 v0.4.0 版本 的 Operator，其中包含大量新功能、修复和可用性改进。
新增内容
自从上次 v0.3.0 版本的 Operator 发布以来，已经有一段时间了。在过去半年中，我们通过 290 次提交添加了新功能，微调了现有功能，并重新编写了文档。
其中一个亮点是，我们现在能够使用 Operator 的 日志丰富器 记录 seccomp 和 SELinux 配置文件。这使得我们能够减少配置文件记录所需的依赖项，只需在节点上运行 auditd 或 syslog（作为备用）。Operator 中的所有配置文件记录都以相同的方式工作，即使用 ProfileRecording CRD 及其相应的标签选择器。日志丰富器本身也可以用于收集有关节点 seccomp 和 SELinux 消息的有意义的见解。请查看官方文档以了解更多信息。
seccomp 相关改进
除了基于日志丰富器的记录之外，我们现在还提供了一种替代方法，通过利用 ebpf 记录 seccomp 配置文件。此可选功能可以通过将 enableBpfRecorder 设置为 true 来启用。这将导致在每个节点上运行一个专用容器，该容器带有一个自定义 bpf 模块来收集容器的系统调用。它甚至支持默认不暴露 BPF 类型格式 (BTF) 的旧内核版本以及 amd64 和 arm64 架构。请查看我们的文档以查看其运行情况。顺便说一下，我们现在还将记录器主机的 seccomp 配置文件架构添加到记录的配置文件中。
我们还将 seccomp 配置文件 API 从 v1alpha1 升级到 v1beta1。这与我们随着时间推移稳定 CRD API 的总体目标相一致。唯一改变的是 seccomp 配置文件类型 Architectures 现在指向 []Arch 而不是 []*Arch。
SELinux 增强功能
SELinux 策略的管理（类似于您通常在单个服务器上调用的 semodule）并非由 SPO 本身完成，而是由另一个名为 selinuxd 的容器完成，以提供更好的隔离。此版本切换到使用来自个人存储库的 selinuxd 容器，转而使用位于 我们团队的 quay.io 存储库下的镜像。selinuxd 存储库也已移至 containers GitHub 组织。
请注意，selinuxd 动态链接到 libsemanage 并从节点挂载 SELinux 目录，这意味着 selinuxd 容器必须运行与集群节点相同的发行版。SPO 默认使用基于 CentOS-8 的容器，但我们也构建基于 Fedora 的容器。如果您使用其他发行版并希望我们为其添加支持，请向 selinuxd 提交问题。
配置文件记录
此版本增加了对 SELinux 配置文件记录的支持。记录本身通过一个 ProfileRecording 自定义资源实例进行管理，如我们存储库中的示例所示。从用户的角度来看，它与 seccomp 配置文件记录的工作方式大致相同。
在底层，为了了解工作负载正在做什么，SPO 在启动时会安装一个特殊的许可策略，名为 selinuxrecording，该策略允许所有操作并将所有 AVC 记录到 audit.log。这些 AVC 消息由日志丰富器组件抓取，当记录的工作负载退出时，策略就会被创建。
SELinuxProfile CRD 毕业
引入了 SelinuxProfile 对象的 v1alpha2 版本。这从对象本身移除了原始的通用中间语言 (CIL)，而是添加了一种简单的策略语言，以简化编写和解析体验。
同时，还引入了一个 RawSelinuxProfile 对象。它包含策略的封装和原始表示。这旨在让人们能够尽快使用他们现有的策略。但是，此处会进行验证。
AppArmor 支持
此版本引入了 AppArmor 的初始支持，允许用户通过使用新的 AppArmorProfile CRD 将 AppArmor 配置文件加载和卸载到集群节点中。
要启用 AppArmor 支持，请使用 SPO 配置的 enableAppArmor 功能门开关。然后使用我们的 apparmor 示例在您的集群中部署您的第一个配置文件。
指标
Operator 现在公开了指标，这些指标在我们的新指标文档中进行了详细描述。我们决定通过使用 kube-rbac-proxy 来保护指标检索过程，同时我们提供了一个额外的 spo-metrics-client 集群角色（和绑定）来从集群内部检索指标。如果您使用的是 OpenShift，那么我们提供了一个开箱即用的 ServiceMonitor 来访问指标。
可调试性和鲁棒性
除了所有这些新功能，我们决定对 Security Profiles Operator 的内部进行部分重构，以使其更易于调试且更健壮。例如，我们现在维护一个内部 gRPC API，用于在 Operator 内部的不同功能之间进行通信。我们还提高了日志丰富器的性能，它现在缓存结果以更快地检索日志数据。通过将 verbosity 从 0 设置为 1，可以将 Operator 置于更详细的日志模式。
我们还在启动时打印所使用的 libseccomp 和 libbpf 版本，并通过 enableProfiling 选项为每个容器公开 CPU 和内存分析端点。Operator 守护程序内部的专用活性和启动探测器现在将进一步改善 Operator 的生命周期。
结论
感谢您阅读此更新。我们期待 Operator 未来的增强，并希望收到您对最新版本的反馈。欢迎通过 Kubernetes Slack #security-profiles-operator 联系我们，提供任何反馈或问题。