概述 近日安全界披露了影响 Red Hat OpenShift AI 的严重安全缺陷,编号为 CVE-2025-10725。尽管厂商将严重等级归为"Important",但该漏洞的 CVSS 得分高达 9.9,若被利用可能导致集群被完全接管,危及混合云环境中 AI 模型、训练数据、推理服务以及底层基础设施的机密性、完整性与可用性。对运行 OpenShift AI(RHOAI)的组织而言,理解漏洞细节、迅速采取缓解和修复措施并开展检测至关重要。 漏洞核心与攻击路径解析 OpenShift AI 是用于管理生成式与预测性 AI 模型生命周期的平台,包含数据准备、模型训练、模型部署与监控等能力。此次漏洞的根源来自于集群角色(ClusterRole)的权限配置过于宽松,具体涉及 kueue-batch-user-role 与 system:authenticated 等主体之间的角色绑定。 攻击者只需拥有一个经过认证的账户,例如数据科学家在 Jupyter Notebook 中的标准用户账号,就可能滥用该角色权限在任何命名空间创建 OpenShift Job。
攻击者能够在受限命名空间之外的特权命名空间(例如 openshift-apiserver-operator)调度恶意 Job,并将其配置为以高权限的 ServiceAccount 运行,从而获取该 ServiceAccount 的令牌并外传。拿到这些令牌后,攻击者可以逐步横向移动,提升至集群管理员权限,最终甚至能够在主节点上获取 root 权限,实现对整个集群的完全接管。 技术细节补充 该漏洞与 Kueue 组件有关。Kueue 是用于批处理工作调度和队列管理的扩展机制,当其 ClusterRole 或 ClusterRoleBinding 错误地允许 system:authenticated(所有通过认证的实体)拥有创建 Job 的能力,就会为低权限账户制造升权路径。Bugzilla 报告指出,任何经过认证的实体,包括用户工作台的低权限服务账户,都能够创建跨命名空间的 Job,从而触发链式权限提升。 影响范围与受影响版本 Red Hat 在公告中列出的受影响版本包括 OpenShift AI 2.16、2.19、2.21 与 2.22。
由于不同组织的 RHOAI 部署场景与配置各异,攻击面大小会有所差别,但凡启用 Kueue 或默认分配了相关 ClusterRoleBinding 的环境均应视为高风险。 时间线与厂商响应 该漏洞在 2025 年 10 月被公开披露,随后 Red Hat 发布了相应的安全公告并给出修复建议。原始建议包括撤销将 kueue-batch-user-role 与 system:authenticated 绑定的 ClusterRoleBinding。后续在 10 月 6 日更新的指南中,Red Hat 给出了若无法立即升级到修复版本(例如 2.16.3 或更高)时的替代缓解措施。 可行缓解与修复建议 升级到厂商提供的修补版本是最可靠的长期解决方案。若短期内无法升级,可按厂商建议采取下列临时缓解措施以降低被利用风险: 将 RHOAI 的 DataScienceCluster 资源中 Kueue 组件的管理状态设置为 Removed,前提是你的环境并不依赖 Kueue 的调度功能。
在确认不需要 Kueue 的场景下,将其禁用可以直接切断攻击链。 在 RHOAI 2.19 及以上版本中,阻止 RHOAI 运维 Operator 对 kueue-batch-user-rolebinding 的管理。通过向相关资源添加指定注解,防止自动化控制器恢复或重新创建易受攻击的绑定配置。 通过更新 ClusterRoleBinding 的主体(subject)为一个不存在的、不可达的组来禁用该绑定。此举能临时撤销对 system:authenticated 的广泛授权。完成补丁安装后,应删除为实施缓解所创建的临时绑定。
整体上遵循最小权限原则,撤销或限制对 system:authenticated 的任何系统级别广泛权限分配,避免将高风险权限暴露给所有认证用户。 检测与事件响应建议 对可能受影响的集群,应立即开展主动审计与检测工作。重点关注以下痕迹与行为: 审计 API 调用日志,检索是否存在在特权命名空间中创建 Job 的记录,尤其是来自非管理员账户或疑似数据科学家工作台的请求。 检查所有 ClusterRoleBinding 与 RoleBinding,确认是否存在将 kueue-batch-user-role 或相似高权限角色绑定到 system:authenticated 或其他广泛主体的情况。 核查近期创建的 ServiceAccount 及其令牌使用痕迹,关注是否有令牌被导出或被挂载到非典型 Pod 中并发出外部请求。 在主节点和控制平面上查找可疑进程、未授权更改和异常登录,必要时将这些节点隔离并进行镜像备份以备取证。
若发现可能的利用行为,应按事件响应流程立刻更换相关 ServiceAccount 令牌、密钥与证书,撤销被怀疑受影响的账户权限,并在受控环境中重建受损组件。 长期安全实践与防御加固 该事件再次强调了在混合云与 AI 平台环境中实施严格访问控制与持续监控的重要性。建议从组织策略与技术防护两方面着手加固: 在 RBAC 策略设计上贯彻最小权限原则,避免赋予系统级角色给大范围主体。定期审计 ClusterRole 与 ClusterRoleBinding,确保没有过度授权。 限制对交互式工作台(如 Jupyter Notebook)的访问与功能,例如通过网络策略隔离未受信任的运行时、限制外网访问权限以及对 Notebook 环境实施时间与资源配额控制。 强化对 ServiceAccount 的管理,包括限制可创建高权限 ServiceAccount 的人员、对敏感 ServiceAccount 的令牌使用进行监控与告警,以及实现令牌短期化与自动轮换机制。
部署和监控审计日志中心,集中分析 Kubernetes 审计日志、API Server 访问记录与控制平面日志,利用行为分析检测异常的资源创建与权限变更行为。 在开发与运维流程中引入基于策略的安全工具(如 OPA Gatekeeper、Kyverno)和合规扫描,阻止有风险的角色绑定、特权 Pod 或不安全的容器配置进入集群。 构建周全的备份与恢复策略,确保关键数据、集群配置与容器镜像在遭受攻击后可快速恢复,并在测试环境中定期演练完整的恢复流程。 组织内沟通与合规考量 对受影响的组织,应该尽快向高层安全负责人和合规团队通报潜在风险、采取的缓解措施与后续修复时间表。对于存在敏感数据或受监管数据的环境,必须评估是否发生数据泄露并按法规要求报告相关事件。 同时,与 Red Hat 支持保持沟通以获得针对特定版本和部署架构的官方指导与补丁信息。
对于托管或云提供商管理的 OpenShift 服务,联系供应商以了解他们是否已经应用了补丁或采取了替代缓解措施。 结语与行动建议 CVE-2025-10725 体现了在 AI 平台与混合云场景下,细微的权限配置失误即可被用作快速的权限提升链,造成灾难性后果。对于运行 Red Hat OpenShift AI 的组织,首要动作是确认是否运行受影响版本并立即评估是否存在易受攻击的 ClusterRoleBinding。能够升级到厂商修补版本的,应尽快完成升级;短期无法升级的,应按官方建议禁用或隔离 Kueue,并撤销将高权限绑定到广泛主体的配置。 在完成补丁或配置修复后,应开展全面的审计与取证,检查是否曾遭到利用并对受影响系统进行彻底清理与重建。长期而言,通过实施严格的 RBAC 管理、持续审计、最小化交互式工作台的风险以及建立自动化合规检测,组织才能在日益复杂的混合云 AI 环境中稳固防线,降低未来类似事件的发生概率。
采取行动现在就开始审查 ClusterRoleBinding、审计日志与工作台访问策略,确保系统处于受控状态并及时应用厂商补丁,以保护你的 AI 平台与混合云基础设施免受全面接管风险。 。
