Capsule项目中Tenant用户可修改kube-system命名空间的安全问题分析

问题背景

在Capsule项目v0.7.2版本中发现了一个潜在的安全问题：Tenant用户和所有者能够修改kube-system命名空间的标签和配置，而系统对其他命名空间的修改请求则会被正确拦截。这一发现源于对AKS（Azure Kubernetes Service）环境下Capsule权限控制的测试。

问题现象

测试人员在多个AKS版本中验证发现，当Tenant用户尝试修改不同命名空间时：

1. 对普通命名空间（如testcapsule01、capsule-system、nginx等）的修改请求会被Capsule正确拦截，并记录"OfflimitNamespace"的拒绝日志
2. 但对kube-system命名空间的修改请求却能够成功执行，系统日志中未显示任何拒绝记录

技术分析

经过深入调查，发现这一现象与AKS平台的特定设计有关：

1. 在AKS环境中，带有特定标签的命名空间（如"control-plane: 'true'"和"kubernetes.azure.com/managedby: aks"）会被视为特殊系统命名空间
2. AKS平台默认允许对这些命名空间进行修改，这是平台设计的一个特性而非漏洞
3. 这种设计可能会影响包括kube-system在内的关键系统命名空间

解决方案

针对这一问题，可以考虑以下解决方案：

1. 配置调整：通过为Capsule的admission webhook配置添加特定标签，可以使其覆盖AKS系统命名空间的保护机制
2. 风险评估：在实施解决方案前，必须评估这一变更对AKS平台操作（如升级、插件管理、命令执行等）的潜在影响
3. 长期方案：在Capsule的AKS基线架构文档中增加相关说明，帮助用户正确理解和配置这一特殊场景

最佳实践建议

1. 生产环境中部署Capsule前，应全面测试其对系统命名空间的影响
2. 定期审计命名空间权限配置，确保没有意外的访问权限泄露
3. 关注AKS平台更新日志，及时了解平台特性的变化
4. 在修改webhook配置前，充分评估其对集群稳定性的影响

总结

这一案例展示了在云托管Kubernetes服务上部署多租户系统时可能遇到的平台特定行为。Capsule项目团队已经意识到这一问题，并将其纳入AKS基线架构的考虑范围。用户在实际部署时应充分了解底层平台的特性，并做好相应的配置调整和风险评估。