OpenKruise项目中的RBAC权限安全风险分析与防护建议

背景

OpenKruise作为Kubernetes的扩展套件，其架构包含两个核心组件：kruise-manager（中心化管理组件）和kruise-daemon（节点管理组件）。在安全评估中发现，kruise-manager默认配置的ClusterRole包含集群级secrets列表权限，这可能成为攻击者实施权限提升的跳板。

风险原理

当组件被授予list secrets这类高权限ClusterRole时，攻击者可能通过以下路径实施攻击：

1. 凭证窃取：获取绑定该ClusterRole的ServiceAccount Token（通过Pod挂载卷或节点secret描述）
2. 权限滥用：
   • 直接利用ClusterAdmin权限Token控制集群
   • 通过创建特权容器挂载主机根目录，窃取master节点kubeconfig

组件权限差异

组件	权限范围	风险影响面
kruise-manager	集群级secrets列表	可能造成集群级权限泄露
kruise-daemon	命名空间级权限	仅影响kruise-system命名空间

防护方案

架构层面

1. 组件隔离部署：将kruise-manager部署在专用节点池，与工作负载物理隔离
2. 网络策略：限制kruise-manager的API Server通信仅允许必要端口

权限控制

1. 最小权限原则：
   • 将kruise-daemon的权限限制为namespace级别
   • 对kruise-manager实施细粒度ResourceNames限制
2. 审计增强：
   • 启用Kubernetes审计日志监控secrets访问行为
   • 配置OPA/Gatekeeper策略拦截异常权限请求

运行时防护

1. Pod安全策略：

   apiVersion: policy/v1beta1
   kind: PodSecurityPolicy
   metadata:
     name: kruise-restricted
   spec:
     allowPrivilegeEscalation: false
     hostPID: false
     hostIPC: false
   

2. 服务账户加固：
   • 为kruise-manager配置自动轮换的短期Token
   • 启用BoundServiceAccountTokenVolume特性

最佳实践建议

1. 生产环境部署时应进行安全评估，明确各组件实际需要的权限
2. 定期使用kube-bench等工具检查RBAC配置
3. 结合CIS Kubernetes Benchmark实施安全基线检查

该风险提示我们：在扩展Kubernetes功能时，需要持续关注控制平面的权限设计，通过架构隔离和权限细化构建纵深防御体系。