Kuberhealthy 项目中 RBAC 权限过大的安全分析

Kuberhealthy 是一个开源的 Kubernetes 集群健康检查工具，用于监控集群中各种资源的状态。近期研究人员发现其部署配置中存在 RBAC 权限过大的问题，可能带来一定的安全隐患。

问题背景

在 Kubernetes 集群中，RBAC（基于角色的访问控制）是保障集群安全的重要机制。每个服务账户只应被授予完成其功能所需的最小权限。然而，Kuberhealthy 的部署配置中，其服务账户被授予了超出实际需求的权限，特别是对 DaemonSet 资源的创建、更新和补丁权限。

风险分析

Kuberhealthy 被授予的 DaemonSet 相关权限存在以下安全风险：

1. 容器隔离风险：利用这些权限创建包含特殊容器的 DaemonSet。这些容器可能具有突破容器隔离的能力。

2. 节点影响：由于 DaemonSet 会在所有或指定节点上运行Pod，可能影响整个集群的工作节点。

3. 多种获取途径：可以通过多种方式获取服务账户令牌，包括供应链问题或应用程序中的代码执行问题。

技术验证

经过代码审查发现：

• Kuberhealthy 确实在 daemonset-check 组件中使用了 DaemonSet 的创建权限
• 但主部署（deployment-check 和 kuberhealthy 主组件）并未使用这些权限
• 当前配置将这些高权限授予了所有组件，违反了最小权限原则

解决方案建议

1. 权限分离：

   • 为不同功能组件创建独立的服务账户
   • 仅授予每个组件完成其功能所需的最小权限
   • 将 DaemonSet 相关权限限制在 daemonset-check 组件

2. 安全策略加固：

   • 使用 Kyverno 或 OPA/Gatekeeper 实施安全策略
   • 限制新创建 Pod 的容器镜像、入口点和命令
   • 强制设置 securityContext，禁用特殊模式和权限提升

3. 运行时保护：

   • 实施 Pod 安全标准（PSP 或其替代方案）
   • 监控异常 DaemonSet 创建行为
   • 定期审计服务账户权限

行业参考

类似问题在其他项目中已被确认，并分配了多个CVE编号。这提醒我们在设计 Kubernetes 控制器时，必须严格遵循最小权限原则，避免因权限过大导致的风险。

总结

Kuberhealthy 项目中的这个案例展示了 Kubernetes 环境中过度授权可能带来的影响。开发者在设计系统架构时，应当仔细评估每个组件所需的权限，并通过合理的权限分离和策略限制来降低潜在风险。对于运维人员来说，在部署类似工具时，也应当审查其RBAC配置，确保符合自身集群的安全要求。