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

在Kubernetes生态系统中，安全配置的平滑升级一直是一个重要课题。本文针对RKE2项目中从Cilium 1.30版本升级时出现的AppArmor注解保留问题进行分析，帮助用户理解这一技术细节及其解决方案。

问题背景

在RKE2集群中使用Cilium作为CNI插件时，当从1.30版本升级时，DaemonSet配置中的AppArmor相关注解会被意外移除。这些注解对于容器安全配置至关重要，特别是当集群启用了AppArmor安全模块时。

技术细节分析

AppArmor是Linux内核的一个安全模块，通过配置profile来限制程序的能力。在Kubernetes中，可以通过两种方式为Pod配置AppArmor：

1. 传统注解方式：使用container.apparmor.security.beta.kubernetes.io/<container_name>注解
2. 新版字段方式：直接在securityContext中指定appArmorProfile字段

在Cilium的DaemonSet配置中，原本同时使用了这两种方式。但在升级到1.30版本时，传统注解方式被意外移除，只保留了securityContext中的配置。

影响评估

虽然从功能角度看，两种配置方式都能实现相同的安全限制，但这种不一致性可能带来以下问题：

1. 配置管理混乱：运维人员可能依赖特定配置方式进行审计或管理
2. 兼容性问题：某些旧版本工具可能依赖传统注解方式
3. 安全策略继承：如果集群中其他工作负载依赖这些注解，可能产生不一致

解决方案验证

在RKE2 v1.31.5-rc2版本中，这个问题已得到修复。验证结果显示：

1. DaemonSet同时保留了两种配置方式：

   appArmorProfile:
     type: Unconfined
   

   和

   container.apparmor.security.beta.kubernetes.io/cilium-agent: unconfined
   container.apparmor.security.beta.kubernetes.io/clean-cilium-state: unconfined
   # 其他容器注解...
   

2. Cilium版本升级到v1.16.5后，所有安全配置保持完整

最佳实践建议

对于使用RKE2和Cilium的用户，建议：

1. 在升级前检查现有集群中的AppArmor配置方式
2. 优先使用v1.31.5及以上版本，确保配置迁移的平滑性
3. 如果必须使用中间版本，需手动验证安全配置是否完整
4. 长期来看，建议逐步迁移到securityContext方式，这是Kubernetes官方推荐的做法

总结

RKE2项目团队及时修复了Cilium升级过程中的AppArmor配置保留问题，体现了对安全配置一致性的重视。用户应当关注这类底层安全配置的变更，确保集群升级不会引入意外的安全策略变化。