近来曝光的 Red Hat OpenShift AI 漏洞 CVE-2025-10725 引发了行业内广泛关注,其 CVSS 评分高达 9.9,尽管 Red Hat 在严重性评估上给出了"important"的标签,但从攻击路径和潜在影响来看,任何能够利用该缺陷的低权限认证用户都可能逐步升级为集群管理员,最终实现对集群主节点的完全接管。这类漏洞对混合云环境和多租户平台构成极高威胁,尤其是那些允许数据科学家或开发者使用 Jupyter Notebook、交互式工作台等自助服务功能的部署环境。理解漏洞细节、快速部署缓解措施并开展事后检测与响应是降低风险的当务之急。 CVE-2025-10725 的核心问题在于 OpenShift AI 中名为 kueue-batch-user-role 的 ClusterRole 被错误地绑定到系统级别的 system:authenticated 组。默认情况下,system:authenticated 包含所有通过认证的主体,这意味着任何登录用户、包括低权限服务账号或临时工作空间的用户,都可以继承到 kueue-batch-user-role 的能力。该角色赋予的关键权限是创建 Kubernetes Job。
单看创建 Job 权限似乎影响有限,但在实际攻击链中,攻击者可以利用 Jobs 在任意命名空间调度短暂运行的 Pod,并在 Pod 中使用高权限的 ServiceAccount 来执行敏感操作。攻击流程通常包含以下阶段。攻击者首先使用一个普通认证账户(例如在 OpenShift AI 中的 Notebook 用户或数据科学家的低权限账号)创建一个 Job,将其目标命名空间指定为具有更高权限的命名空间,例如平台的管理命名空间或包含关键服务的系统命名空间。接着,攻击者在 Job 的 Pod 模板中指定一个高权限的 ServiceAccount 名称,或者利用平台上已有的高权限 ServiceAccount。如果平台没有对 ServiceAccount 的使用进行严格限制或审计,Job 启动后可以访问该 ServiceAccount 的令牌。容器启动后,恶意镜像或运行的脚本会读取挂载到 Pod 中的 ServiceAccount 令牌并将其回传到攻击者可控的位置。
获得高权限 ServiceAccount 令牌后,攻击者即可通过 Kubernetes API 执行一系列特权操作,包括创建 ClusterRoleBinding、部署具有 hostPath 或特权模式的 Pod、访问敏感 Secret、读取或修改 etcd 数据,进一步扩展对控制平面的影响,最终实现对集群主节点的根级访问。该攻击链之所以危险,部分原因来自 OpenShift AI 的使用场景。平台鼓励研究人员和数据团队在受控环境中快速部署实验工作负载,这类环境往往为了便捷会放宽部分权限控制或保留可供团队自助使用的共享资源。只要任一受信任边界被跨越,攻击者便能利用看似无害的权限实现横向移动与等级提升。面对这一类高危漏洞,首要的应对措施是按厂商建议立即移除或修改危险的 ClusterRoleBinding。Red Hat 的缓解建议是删除将 kueue-batch-user-role 绑定到 system:authenticated 的 ClusterRoleBinding。
更安全的做法是将创建 Job 的权限按需分配给特定用户或用户组,遵循最小权限原则,避免将集群范围的权限授予广泛的系统级别组。除了直接消除该错误绑定,建议对平台的 RBAC 策略进行全面审计,确认没有其他角色被错误绑定到 system:authenticated 或 system:serviceaccounts 等广泛组。审计内容应包括 ClusterRole、Role、RoleBinding 和 ClusterRoleBinding 的逐项检查,重点关注对 batch/v1/jobs、pods、secrets、serviceaccounts、clusterroles 和 clusterrolebindings 等资源的写入权限。检测和事件响应的准备工作同样重要。假设已经发生入侵或存在被利用的风险,安全团队需要进行全面的搜索与取证。首要检测指标应包括近期创建的 Jobs,尤其是在非典型命名空间或管理命名空间中出现的 Job,以及指定非本命名空间 ServiceAccount 的 Job。
Kubernetes 审计日志和 OpenShift 审计日志是关键情报来源,通过筛选 apiVersion=batch/v1, verb=create, resource=jobs 的事件可以快速定位可疑活动。与此同时,应检查最近创建的 ServiceAccounts、Secrets 与 ClusterRoleBinding。对 etcd 访问模式、API Server 的异常请求量、以及短时间内大量创建资源的行为也要保持警惕。对可疑 Pod 的容器镜像进行溯源和静态分析,识别是否携带数据外发逻辑或包含已知的恶意二进制/脚本。一旦确认存在滥用,应立刻采取多步恢复操作。首要行动包括撤销对被滥用 ServiceAccount 的令牌、删除被攻击者创建的 ClusterRoleBinding 并重新评估集群管理员账户的凭据。
对被怀疑受影响的 ServiceAccount 进行更换并重新颁发令牌,删除可疑的 Jobs 和 Pod,并在必要时对受影响节点和控制平面执行深度取证与清理。若存在对 etcd 或控制平面的直接篡改风险,应考虑在受信任的离线环境中恢复集群或使用已知安全的备份进行恢复,并更换集群证书与密钥。为降低类似事件再次发生的概率,平台应引入更严格的防护和治理机制。使用基于策略的准入控制可在资源创建阶段阻止危险行为,例如禁止普通用户在管理命名空间中创建 Job,阻止指定 ServiceAccount 被非授权主体引用,或阻止运行特权容器和挂载敏感主机路径。Open Policy Agent(OPA)与 Gatekeeper 等工具可用来实现这些策略的持续强制。Pod 安全策略和 PodSecurity Admission 的配置应限制容器的特权标志、root 运行和主机卷挂载。
对服务账号令牌的访问策略也要收紧,启用 TokenProjection 并限制自动挂载,避免将高权限令牌直接暴露给临时工作负载。网络层面上应限制集群内部的横向流量,使用网络策略阻断不同命名空间或工作负载间不必要的访问路径。记录与监控体系需要增强,以便在攻击发生初期快速发现异常。集群应启用和集中收集 kube-audit、API 服务器日志、控制平面组件日志以及容器运行时日志。将这些日志输入到 SIEM 或安全分析平台,配置对资源创建、权限变更、异常外联、以及异常镜像拉取的告警规则。结合行为检测引擎与威胁情报,可以更快识别入侵者的后续动作。
除技术措施外,组织流程和人员准备也不可忽视。制定与演练针对集群级别入侵的应急响应流程,明确谁负责隔离受影响资源、谁执行凭证轮换、谁与厂商协调 Patch。为开发与数据科学团队提供关于最小权限原则与安全镜像使用的培训,减少因便捷性引入的权限滥用风险。供应链安全与镜像管理也是长期防护的要点。确保容器镜像来自受信任的仓库,对镜像进行签名与扫描,阻止拉取未经验证或含有高风险组件的镜像。采用持续合规扫描工具对集群配置和 workload 进行基线检测,及时识别与修复偏离策略的配置项。
了解漏洞评分与分级方式的差异也有助于合理安排响应优先级。厂商在漏洞公告中有时会根据漏洞的先决条件与可利用难度对严重性做出调整。在 CVE-2025-10725 的例子中,Red Hat 将问题列为"important"部分原因是漏洞需要认证访问才可触发。然而在多租户或允许用户自助创建资源的环境中,认证的门槛并不能有效降低风险。安全团队应基于自身环境的实际暴露面与可利用路径来评估优先级,而不是仅依赖外部评分。此外,应当考虑到漏洞被链式利用的可能性。
攻击者通常不会满足于单项权限,他们会组合多个配置缺陷与默认宽松权限形成可行的攻击链。逐步提升权限、获取凭证并持续潜伏直至横向扩张,是常见的策略。预防此类连锁反应的关键在于将权限最小化、强化审计并减少攻击面。最后,厂商与社区的沟通也很重要。OpenShift 平台管理员应密切关注 Red Hat 与相关安全组织发布的补丁、缓解建议和利用路径解析。对于无法立即打补丁的环境,应立即实施临时的配置变更以降低风险,并在安全通告发布后优先安排补丁部署和验证。
与云服务提供商或托管服务团队保持联动,确保多租户环境中不存在因权限默许而导致的进一步暴露风险。综上所述,CVE-2025-10725 暴露了在复杂平台中,当对系统级别组赋予过宽权限时潜在的极高风险。及时删除错误的 ClusterRoleBinding、对 RBAC 策略进行审计、强化准入控制、提升日志与监控能力、实行凭证轮换与最小权限原则,能够显著降低被滥用的概率。对安全团队来说,最重要的是以"假设已被入侵"的心态进行主动搜证与清理,确保平台修补与恢复后的状态满足长期安全与合规要求。 。
