您现在的位置是：首页 > 文章详情

Security Profiles Operator 发布 v0.4.0

日期：2021-12-20点击：492收藏

作者：Jakub Hrozek、Juan Antonio Osorio、Paulo Gomes、Sascha Grunert

安全分析文件操作器（Security Profiles Operator，SPO[1]）是 out-of-tree Kubernetes 的一种改进，可以使 seccomp、SELinux 和 AppArmor 分析文件的管理更容易、更方便。我们很高兴地宣布，我们最近发布了 v0.4.0，其中包含了大量的新特性、修复和可用性改进。

有什么新鲜事

从操作器的上一个 v0.3.0 版本到现在已经有一段时间了。在过去的半年里，我们在 290 次提交中添加了新的特性，调整了现有的特性，并重新编写了我们的文档。

其中一个亮点是，我们现在能够使用操作器的日志丰富器记录 seccomp 和 SELinux 分析文件。这允许我们减少在节点上运行 auditd 或 syslog（作为回退）时记录概要文件所需的依赖关系。通过使用 ProfileRecording CRD 及其相应的标签选择器，操作器中的所有分析文件记录都以相同的方式工作。日志丰富器本身也可以用来收集关于节点的 seccomp 和 SELinux 消息的有意义的见解。请查看官方文档[2] 以了解更多有关它的信息。

seccomp 相关改进

除了基于日志丰富器的记录，我们现在提供了一个替代方式，使用 ebpf 记录 seccomp 分析文件。这个可选特性可以通过将 enableBpfRecorder 设置为 true 来启用。这导致运行一个专用容器，该容器在每个节点上附带一个自定义 bpf 模块来收集容器的系统调用。它甚至支持不暴露 BPF 类型格式（BTF）的旧内核版本以及 amd64 和 arm64 架构。请查看我们的文档[3] 以查看它的运行情况。顺便说一下，我们现在也将记录器主机的 seccomp 概要架构添加到已记录的概要文件中。

我们还将 seccomp 概要文件 API 从 v1alpha1 升级到 v1beta1。这与我们随时间稳定 CRD API 的总体目标一致。唯一改变的是，seccomp profile type Architectures 现在指向[]Arch，而不是[]*Arch。

SELinux 的增强

管理 SELinux 策略（相当于使用通常在单个服务器上调用的 semmodule）不是由 SPO 本身完成的，而是由另一个名为 selinuxd 的容器来提供更好的隔离。这个版本从使用来自个人仓库的 selinuxd 容器，转到使用位于我们团队在 quay.io 的镜像[4]。selinuxd 仓库也移到了 containers 的 GitHub 组织[5] 中。

请注意，selinuxd 动态链接到 libsemanage，并从节点挂载 SELinux 目录，这意味着 selinuxd 容器必须运行与集群节点相同的发行版。SPO 默认使用基于 CentOS-8 的容器，但是我们也构建基于 Fedora 的容器。如果你正在使用另一个发行版，并且希望我们添加对它的支持，请向 selinuxd 提交一个问题[6]。

分析文件记录

这个版本增加了对 SELinux 分析文件记录的支持。记录本身是通过 ProfileRecording Custom Resource 的一个实例来管理的，如仓库中的这个示例[7] 所示。从用户的角度来看，它的工作原理和记录 seccomp 分析文件差不多。

在幕后，为了知道工作负载正在做什么，SPO 在启动时安装了一个特殊的允许策略，名为 selinuxrecording[8]，该策略允许所有事情和记录所有 AVC 到 audit.log。这些 AVC 消息由日志充实器组件抓取，当记录的工作负载退出时，创建策略。

SELinuxProfile CRD 毕业

引入了 SelinuxProfile 对象的 v1alpha2 版本。这从对象本身删除了原始的公共中间语言（Common Intermediate Language，CIL），而是添加了一个简单的策略语言来简化编写和解析体验。

此外，还引入了 RawSelinuxProfile 对象。它包含策略的包装和原始表示。这是为了让人们能够尽快使用他们现有的政策。然而，这里完成了验证。

对 AppArmor 支持

这个版本引入了对 AppArmor 的初始支持，允许用户使用新的 AppArmorProfile CRD 将 AppArmor 分析文件加载和卸载到集群节点中。

要启用 AppArmor 支持，请使用 SPO 分析中的 enableAppArmor 功能门开关。然后使用我们的 apparmor 示例跨集群部署第一个分析文件。

度量

操作器现在暴露度量，在我们新的度量文档[9] 中详细描述了这些度量。我们决定通过使用 kube-rbac-proxy 来确保指标检索过程的安全性，同时我们提供了一个额外的 spoi -metrics-client 集群角色（和绑定）来从集群内检索度量。如果你正在使用 OpenShift，那么我们将提供一个开箱即用的 ServiceMonitor 来访问度量。

Debuggability 和健壮性

除了所有这些新功能，我们决定在内部重组部分安全分析文件操作器，使其更好地调试和更健壮。例如，我们现在维护一个内部 gRPC API，以便在操作器内部跨不同功能进行通信。我们还改进了日志丰富器的性能，现在它缓存结果以更快地检索日志数据。通过将 verbose 值从 0 设置为 1，可以将操作器设置为更详细的日志模式。

我们还在启动时打印使用的 libseccomp 和 libbpf 版本，并通过 enableProfiling 选项暴露每个容器的 CPU 和内存分析端点。现在，操作器守护进程中的专用活动和启动探测将进一步改善操作器的生命周期。