Kuberhealthy 项目中的 RBAC 权限过度分配问题分析

Kuberhealthy 是一款流行的 Kubernetes 集群健康检查工具，但在其最新版本中发现了一个潜在的安全隐患。该问题涉及 RBAC（基于角色的访问控制）权限分配不当，可能导致集群安全风险。

问题背景

Kuberhealthy 部署时自动创建的 ClusterRole 包含了超出实际需求的权限，特别是对 DaemonSet 资源的创建、更新和补丁操作权限。这些高权限操作本应只授予必要的组件，但当前实现中却被默认分配给 Kuberhealthy 服务账户。

技术分析

经过对 Kuberhealthy 源代码的深入审查，我们发现：

1. 主部署（Deployment kuberhealthy）并不需要 DaemonSet 相关权限来执行其核心功能
2. 只有特定的 daemonset-check 组件才真正需要创建 DaemonSet 的权限
3. 当前实现将所有权限集中在一个 ClusterRole 中，违反了最小权限原则

潜在风险

这种权限过度分配可能带来严重的安全隐患：

1. 容器逃逸风险：攻击者可以利用 DaemonSet 创建权限部署特权容器，通过容器逃逸技术获取节点 root 权限
2. 横向移动攻击：由于 DaemonSet 可以在所有节点上部署 Pod，攻击者可借此控制整个集群
3. 供应链攻击放大：任何能够获取服务账户令牌的攻击者都能利用这些高权限

解决方案建议

针对此问题，我们提出以下改进建议：

1. 权限分离：为不同组件创建独立的 ServiceAccount 和 Role/RoleBinding
2. 最小权限原则：仅授予组件执行其功能所需的最小权限集
3. 安全策略加固：
   • 使用 Kyverno 或 OPA/Gatekeeper 限制 Pod 创建参数
   • 强制设置安全上下文，禁用特权容器
   • 实施镜像来源控制策略

实施考量

在实施权限调整时需要考虑：

1. 向后兼容性：确保变更不会影响现有部署
2. 功能完整性：验证所有检查功能在权限调整后仍能正常工作
3. 监控机制：增加权限使用审计日志，便于问题排查

总结

Kuberhealthy 作为集群健康监控工具，其自身的安全性尤为重要。通过合理的权限重构和安全加固，可以在不影响功能的前提下显著提升整体安全性。建议项目维护者优先考虑这些改进措施，以保护用户集群免受潜在攻击。