这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。

Security Profiles Operator v0.4.0 中的新功能

2021.12.17

作者: Jakub Hrozek, Juan Antonio Osorio, Paulo Gomes, Sascha Grunert

Security Profiles Operator (SPO) 是一种树外 Kubernetes 增强功能，用于更方便、更便捷地管理 seccomp、 SELinux 和 AppArmor 配置文件。我们很高兴地宣布，我们最近发布了 v0.4.0 的 Operator，其中包含了大量的新功能、缺陷修复和可用性改进。

有哪些新特性

距离上次的 v0.3.0 的发布已经有一段时间了。在过去的半年里，我们增加了新的功能，对现有的功能进行了微调，并且在过去的半年里，我们通过 290 个提交重新编写了文档。

亮点之一是我们现在能够使用 Operator 的日志增强组件记录 seccomp 和 SELinux 的配置文件。这使我们能够减少配置文件记录所需的依赖事项，使得仅剩的依赖变为在节点上运行 auditd 或 syslog（作为一种回退机制）。通过使用 ProfileRecording CRD 及其对应的标签选择算符， Operator 中的所有配置文件记录都以相同的方式工作。日志增强组件本身也可用于获得有关节点上的 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 仓库也已移至GitHub 组织 containers。

请注意，selinuxd 动态链接到 libsemanage 并挂载节点上的 SELinux 目录，这意味着 selinuxd 容器必须与集群节点运行相同的发行版。SPO 默认使用基于 CentOS-8 的容器，但我们也构建基于 Fedora 的容器。如果你使用其他发行版并希望我们添加对它的支持，请针对 selinuxd 提交 issue。

配置文件记录

此版本（0.4.0）增加了记录 SELinux 配置文件的支持。记录本身是通过 ProfileRecording 自定义资源的实例管理的，如我们仓库中的示例所示。从用户的角度来看，它的工作原理与记录 seccomp 配置文件几乎相同。

在后台，为了知道工作负载在做什么，SPO 安装了一个名为 selinuxrecording 的、限制宽松的策略，允许执行所有操作并将所有 AVC 记录到 audit.log 中。这些 AVC 消息由日志增强组件抓取，当所记录的工作负载退出时，该策略被创建。

`SELinuxProfile` CRD 毕业

我们引入了 SelinuxProfile 对象的 v1alpha2 版本。这个版本从对象中删除了原始的通用中间语言 (CIL)，并添加了一种简单的策略语言来简化编写和解析体验。

此外，我们还引入了 RawSelinuxProfile 对象。该对象包含策略的包装和原始表示。引入此对象是为了让人们能够尽快将他们现有的策略付诸实现。但是，策略的验证是在这里完成的。

AppArmor 支持

0.4.0 版本引入了对 AppArmor 的初始支持，允许用户通过使用新的 AppArmorProfile 在集群节点中 CRD 加载或卸载 AppArmor 配置文件。

要启用 AppArmor 支持，请使用 SPO 配置的 enableAppArmor 特性门控开关。然后使用我们的 apparmor 示例在集群中部署你第一个配置文件。

指标

Operator 现在能够公开在我们的新指标文档中详细描述的指标。我们决定使用 kube-rbac-proxy 来保护指标检索过程，同时我们提供了一个额外的 spo-metrics-client 集群角色（和绑定）以从集群内检索指标。如果你使用 OpenShift，那么我们提供了一个开箱即用的 ServiceMonitor 来访问指标。

可调试性和稳健性

除了所有这些新功能外，我们还决定在内部重组安全配置文件操作程序的部分内容，使其更易于调试和更稳健。例如，我们现在维护了一个内部 gRPC API，以便在 Operator 内部跨不同功能组件进行通信。我们还提高了日志增强组件的性能，现在它可以缓存结果，以便更快地检索日志数据。 Operator 可以通过将 verbosity 设置从 0 改为 1，启用更详细的日志模式(https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#set-logging-verbosity)。

我们还在启动时打印所使用的 libseccomp 和 libbpf 版本，并通过 enableProfiling 选项公开每个容器的 CPU 和内存性能分析端点。 Operator 守护程序内部的专用的存活态探测和启动探测现在能进一步改善 Operator 的生命周期管理。

总结

感谢你阅读这次更新。我们期待着 Operater 的未来改进，并希望得到你对最新版本的反馈。欢迎通过 Kubernetes slack #security-profiles-operator 与我们联系，提出任何反馈或问题。