RKE2项目中Cilium升级时AppArmor注解保留问题分析

在RKE2项目中使用Cilium网络插件时，从1.30版本升级过程中发现了一个关于AppArmor安全配置的重要问题。本文将深入分析该问题的技术背景、影响范围以及解决方案。

问题背景

AppArmor是Linux内核的一个安全模块，用于通过配置文件限制程序的能力。在Kubernetes中，可以通过注解(annotations)为Pod或容器指定AppArmor配置。Cilium作为Kubernetes CNI插件，其DaemonSet中包含了多个容器，每个容器都需要适当的AppArmor配置以确保安全性。

问题现象

在RKE2从1.30.8升级到1.30.9-rc2版本时，发现Cilium DaemonSet中的部分AppArmor注解在升级过程中被意外移除。具体表现为：

1. 升级前，Cilium Pod中包含多个容器的AppArmor注解，如：

   • container.apparmor.security.beta.kubernetes.io/cilium-agent
   • container.apparmor.security.beta.kubernetes.io/clean-cilium-state
   • container.apparmor.security.beta.kubernetes.io/mount-cgroup等

2. 升级后，部分注解丢失，可能导致安全配置不完整

技术分析

这个问题源于Cilium Helm chart在1.30版本中的变更。新版本中，Cilium的部署模板进行了重构，优化了安全相关的配置方式，但在这个过程中，对旧版注解的处理不够完善，导致升级时部分注解被丢弃。

在Kubernetes中，AppArmor支持两种配置方式：

1. 通过Pod注解(annotations)为每个容器单独配置
2. 通过PodSecurityContext中的appArmorProfile字段统一配置

新版本倾向于使用第二种更现代的方式，但在迁移过程中需要确保向后兼容性。

影响评估

该问题主要影响以下场景：

1. 从旧版RKE2升级到1.30.x版本的用户
2. 依赖特定AppArmor配置的安全敏感环境
3. 使用自定义安全策略的环境

如果不修复，可能导致：

• 部分容器失去预期的安全限制
• 安全策略不一致
• 潜在的安全风险

解决方案

RKE2团队在1.30.9-rc2版本中修复了这个问题，确保：

1. 保留所有传统的AppArmor注解
2. 同时支持新的appArmorProfile配置方式
3. 确保升级过程平滑，不影响现有部署

验证方法：

1. 检查DaemonSet中的annotations是否完整
2. 确认各容器的实际AppArmor配置
3. 验证安全功能是否正常

最佳实践

对于RKE2用户，建议：

1. 升级前检查现有的AppArmor配置
2. 优先使用1.30.9及以上版本
3. 升级后验证所有安全相关配置
4. 考虑逐步迁移到新的appArmorProfile配置方式

总结

RKE2项目对Cilium升级过程中AppArmor注解丢失问题的修复，体现了对安全性和升级体验的重视。这种对细节的关注确保了用户环境的安全配置在版本迭代中保持完整和一致，是基础设施软件成熟度的重要体现。