本文已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已失效。
Security Profiles Operator v0.4.0 的新特性
Security Profiles Operator (SPO) 是一个树外 Kubernetes 增强功能，旨在使 seccomp、SELinux 和 AppArmor 配置文件的管理更容易、更方便。我们很高兴地宣布，我们最近发布了该 Operator 的 v0.4.0 版本，其中包含大量新功能、修复和可用性改进。
新特性
自 Operator 上一个v0.3.0 版本发布以来已有一段时间。在过去半年里，我们通过 290 次提交，增加了新功能，优化了现有功能，并重写了文档。
其中一个亮点是，我们现在可以使用 Operator 的日志丰富器来记录 seccomp 和 SELinux 配置文件。这使我们能够减少配置文件记录所需的依赖项，只需在节点上运行 auditd 或 syslog（作为备选）。Operator 中的所有配置文件记录都以相同的方式工作，即使用 ProfileRecording CRD 及其相应的标签选择器。日志丰富器本身也可用于收集关于节点上 seccomp 和 SELinux 消息的有意义的洞察。请查阅官方文档了解更多信息。
seccomp 相关改进
除了基于日志丰富器的记录方式，我们现在还提供了一种利用 ebpf 记录 seccomp 配置文件的替代方案。可以通过将 enableBpfRecorder 设置为 true 来启用此可选功能。这会在每个节点上运行一个专用容器，其中包含一个自定义 bpf 模块，用于收集容器的系统调用。它甚至支持默认不暴露 BPF Type Format (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 提交 issue。
配置文件记录
此版本增加了对 SELinux 配置文件记录的支持。记录本身通过 ProfileRecording Custom Resource 的实例进行管理，如我们仓库中的示例所示。从用户的角度来看，其工作原理与记录 seccomp 配置文件非常相似。
在底层，为了了解工作负载正在做什么，SPO 在启动时安装了一个名为 selinuxrecording 的特殊 permissive 策略，该策略允许所有操作并将所有 AVC 记录到 audit.log。这些 AVC 消息由日志丰富器组件抓取，当被记录的工作负载退出时，策略就被创建出来。
SELinuxProfile CRD 升级
引入了 SelinuxProfile 对象的 v1alpha2 版本。这移除了对象本身的原始 Common Intermediate Language (CIL)，并代之以简单的策略语言，以简化编写和解析体验。
同时，还引入了 RawSelinuxProfile 对象。它包含策略的封装和原始表示。这样做是为了让人们能够尽快使用他们现有的策略。但是，在此进行验证。
AppArmor 支持
此版本引入了对 AppArmor 的初步支持，允许用户通过使用新的 AppArmorProfile CRD 将 AppArmor 配置文件加载和卸载到集群节点中。
要启用 AppArmor 支持，请使用 SPO 配置中的enableAppArmor 特性门开关。然后使用我们的apparmor 示例将您的第一个配置文件部署到集群中。
指标
该 Operator 现在公开了指标，这些指标在我们新的指标文档中详细描述。我们决定通过使用kube-rbac-proxy 来保护指标检索过程，同时我们还附带了一个额外的 spo-metrics-client cluster role（及绑定）以从集群内部检索指标。如果您正在使用OpenShift，我们将提供一个开箱即用的ServiceMonitor 来访问这些指标。
可调试性和健壮性
除了所有这些新功能之外，我们还决定对 Security Profiles Operator 的内部部分进行重构，以使其更容易调试和更健壮。例如，我们现在维护一个内部 gRPC API，用于在 Operator 内部不同功能之间进行通信。我们还提高了日志丰富器的性能，它现在缓存结果以更快地检索日志数据。通过将 verbosity 从 0 设置为 1，可以将 Operator 置于更详细的日志模式。
我们还在启动时打印使用的 libseccomp 和 libbpf 版本，并通过enableProfiling 选项公开每个容器的 CPU 和内存分析端点。Operator 守护程序内的专用 liveness 和 startup 探针现在还将进一步改善 Operator 的生命周期。
结论
感谢阅读此更新。我们期待 Operator 未来的增强功能，并非常乐意收到您对最新版本的反馈。如有任何反馈或问题，请随时通过 Kubernetes slack #security-profiles-operator 联系我们。