事件概述：租一个集群，最后摸到了整朵云
2026 年 10 月 22 日，卡巴斯基安全研究员 Matvey Bukhtoyarov 在安全分析师峰会（SAS 2026）上发表了题为“Smash the Tenant Boundary”（打穿租户边界）的技术演讲；10 月 27 日，卡巴斯基 Securelist 博客公开了完整技术复盘。研究源于一次官方漏洞悬赏（bug bounty）授权下的渗透测试，对象是一家大型云服务商的托管平台（卡巴斯基按约定对厂商做了匿名化处理），该案例还获得了俄罗斯渗透测试大奖 2026“系统黑客（Web 与逻辑）”类别第二名。
结论用一句话概括：一名只拥有普通租户权限的测试者，从自己“租来的”一个托管 Kubernetes 集群出发，先后完成容器逃逸、控制平面远程代码执行、本地提权，横向读到了其他租户的日志和 root SSH 私钥，并连续攻陷平台托管的 Kafka、Redis、PostgreSQL、MySQL，最终触达管理整个云的 SaltStack 管理层。卡巴斯基在报告中明确写道：拿到 Salt master 和生产云数据库“将有可能接管所有资源”——按与厂商的约定，测试到此为止。所有问题均已在负责任披露流程中修复，该平台现有客户无需打补丁，但这条链路本身，值得所有做多租户平台的团队逐项对照。
漏洞链详解：八步走是如何串起来的
这条链路没有哪一个单独漏洞是“惊天动地”的，真正的问题是平台内部服务之间“谁都信谁”的信任关系被一步步串成了链。
第一步，特权 Pod 逃逸到 worker 节点。托管 Kubernetes 集群基于 k0s v1.25.16+k0s.0 构建，其默认安全策略没有阻止租户创建带主机命名空间的特权 Pod（hostPID 等）。测试者创建特权 Pod 后用 nsenter 进入宿主机命名空间，直接获得 worker 节点 root。托管服务通常刻意不向租户开放 worker 节点 SSH，这道边界就这样被绕过了。
第二步，Konnectivity 服务端请求伪造（SSRF）。Konnectivity 是 Kubernetes 控制平面与工作节点之间的隧道组件。测试者在 worker 节点上发现了 Konnectivity agent 的令牌，进一步阅读 k0s 使用的 Konnectivity 服务端代码后发现：服务端收到来自 worker 侧的 DIAL_REQ 连接请求包后，会在控制平面上直接执行 net.Dial()，却不校验协议和目标地址——攻击者可以让控制平面代为连接任意地址，包括本地 Unix 域套接字。Mirantis（k0s 背后的公司）已确认该漏洞并发布安全公告 GHSA-3588-pcxv-rx45，修复版本为 v1.28.2+k0s.0，1.27 及更早版本线受影响。
第三步，借 D-Bus 在控制平面执行代码。通过这个 SSRF，测试者访问到控制平面上的 D-Bus 系统套接字（/run/dbus/system_bus_socket），先通过 systemd user lingering 为当前用户启用常驻服务，再用 StartTransientUnit 启动瞬时单元执行任意命令，拿到控制平面的远程代码执行（当时还不是 root 权限）。
第四步，OverlayFS 本地提权。控制平面主机运行 Ubuntu 22.04（内核 5.15.x），测试者利用已知的 OverlayFS 本地提权漏洞 CVE-2023-32629（用户命名空间处理缺陷，复制的 Python 3 解释器保留了 cap_setuid+eip 能力），提升为 root。
第五步，一张扁平的 overlay 网络。拿到控制平面 root 后，一张连接全部托管服务的扁平 overlay 网段（100.64.0.0/10）暴露出来，测试者还回收到了 salt-minion 密钥对——这是通往云自身管理层 SaltStack 的钥匙。
第六步，监控数据里躺着租户的秘密。VictoriaMetrics 的 /api/v1/targets 接口列出了平台上所有托管资源的元数据（集群 ID、内网 IP、客户命名空间）；未认证的 VictoriaLogs（9428 端口）允许查询全平台日志。关键在于：cloud-init 默认脚本为托管 K8s 节点生成 root SSH 私钥后，竟把私钥明文打印到了标准输出、落进了日志。元数据与日志一关联，其他租户的集群控制权便随之易手。
第七步，托管数据库连环失陷。Kafka 的 JMX Registry（9999 端口）RMI 无认证且 stub host 暴露在 overlay 网上，通过 mlet 远程加载恶意 MBean 即达成代码执行；redis_exporter（9121 端口）的 /scrape 端点接受任意目标参数并附带自身 Redis 凭证去连接，等于把口令“送”到攻击者监听端；Patroni/PostgreSQL 旁的 etcd（2379 端口）无任何访问控制，改写其配置键中的 archive_command、触发角色切换与重启，即可以数据库权限执行任意命令，节点备份目录里还躺着明文 S3 凭证；MySQL 则被 API 层 CRLF 注入覆盖 secure_file_priv 与 plugin_dir，写入含 UDF 的 .so 完成命令执行，再借助 mysql-watcher.service 落地 SUID shell。
第八步，管理平面。Salt pillar 脚本存在 SQL 注入，暴露的 Salt master 令牌可以对每一台受管主机执行命令。卡巴斯基直言，这一步再往前就是“接管所有资源”，因此依约停手。
为什么普通用户、站长和运维要关注
“云上泄露大多是客户自己配置错了”——存储桶开太宽、端口暴露太多，这类故事大家听得很多。这个案例的价值在于：每一环弱点都位于服务商侧，与客户怎么配置毫无关系。一个普通租户能摸到别的租户的集群和数据库，靠的不是客户失误，而是平台内部服务之间的信任被串联放大。
对在云上租用托管 Kubernetes 的个人开发者和中小企业来说，这件事至少说明三点：其一，多租户隔离不是买了托管服务就自动成立的“黑盒承诺”，平台方的基础设施安全水平是你安全边界的一部分；其二，遇到平台安全事件时，“厂商是否及时通知、是否公开修复细节、是否有漏洞悬赏和渗透测试机制”，应该成为选型和续约时的参考项；其三，日志里出现明文私钥、监控端点无认证、etcd 无认证可达——这些问题在任何自建环境里都并不罕见，值得回头看一眼自己的服务器。
对自建多租户平台的团队（包括给内部多条业务线提供 K8s 的平台组），卡巴斯基这条链路几乎就是一份现成的检查清单：租户能不能建特权 Pod、worker 侧流量是否被当作不可信输入、控制面内核补丁是否和租户节点同步、管理端口是否只监听在必要范围、日志和指标库里有没有敏感信息。
攻击风险与利用前提
需要说明的是，这项研究是在官方 bug bounty 授权下完成的合规测试，所有漏洞已在披露后修复，截至卡巴斯基发稿没有证据表明该链路被真实攻击者利用。利用的前提条件也比较明确：攻击者需要拥有该平台的普通租户身份（有权限创建 Pod），并且其节点能到达平台内部 overlay 网段。对使用 k0s 1.27 及更早版本线自建或提供托管 K8s 的平台方来说，Konnectivity 的 SSRF 问题（GHSA-3588-pcxv-rx45）是必须处理的一项。卡巴斯基在报告中还提到 Valkey 的 CVE-2026-25243（RESTORE 堆溢出，亦已被用于攻击 Redis）可作为另一条横向路径，使用 Valkey/Redis 的环境同样应关注补丁窗口。
排查思路：平台方可以对照检查的几件事
如果你负责的平台向他人提供 Kubernetes 或数据库托管服务，可以按下面的顺序做一轮自查（建议在测试环境验证，避免影响生产）：
1. Pod 安全策略是否真的生效。用普通租户身份尝试创建带 hostPID/hostNetwork/privileged 的 Pod，确认被准入策略（Pod Security Admission“restricted”或 Kyverno/Gatekeeper 等效策略）拒绝，而不是仅依赖文档声明。
2. k0s 版本与 Konnectivity。核对集群 k0s 版本，对照 GHSA-3588-pcxv-rx45 公告确认是否在受影响范围；检查 Konnectivity 服务端是否已升级，worker 侧发起的连接请求是否按不可信输入校验目标地址。
3. 控制面内核补丁覆盖。CVE-2023-32629 这类 OverlayFS 本地提权的修复，是否覆盖控制平面和管理面主机，而只修了租户节点。
4. 管理端口暴露面。梳理 JMX/RMI（9999）、etcd（2379）、redis_exporter（9121）、VictoriaLogs（9428）等端口是否绑定在 loopback 或加了认证与网络策略，overlay 网段是否扁平到“一个租户的节点能看到所有人的服务”。
5. 日志与指标库搜敏感信息。在日志和监控存储中检索 “BEGIN RSA PRIVATE KEY”“BEGIN OPENSSH PRIVATE KEY” 等私钥特征和明文口令，检查 cloud-init 与运维脚本是否把密钥打印到了 stdout。
修复与缓解建议
优先按官方公告升级：k0s 使用方应按 GHSA-3588-pcxv-rx45 升级到修复版本 v1.28.2+k0s.0 或按公告指引操作；升级前备份集群配置，先在测试环境验证，安排维护窗口执行，并提前评估重启控制面组件对集群管理面的业务影响。
其余措施按优先级推进：对租户集群强制 Pod Security Admission“restricted”或等效策略，禁止 hostPID/hostNetwork/privileged 容器（策略变更先测试集群验证）；将 JMX/RMI、etcd、redis_exporter、VictoriaLogs 等管理端点收敛到 loopback 或加认证（调整监听地址和防火墙规则前，先备份配置并评估业务影响）；把 cloud-init 曾打印到日志的 SSH 私钥做轮换（先在测试环境验证新密钥可用、保留旧通道直至确认，再全面切换）；停止将密钥输出到 stdout 与日志；把控制面、管理面主机纳入 OverlayFS 类本地提权漏洞的修复范围，内核更新涉及重启的按维护窗口推进。
需要强调：本文涉及的版本号与公告号请以 Mirantis 与卡巴斯基官方发布为准；生产环境操作前请备份配置、评估业务影响，不要在没有任何验证的情况下直接改动防火墙或重启服务。
后续观察
这件事之后值得持续关注的有几条线：k0s 与上游 Konnectivity 对“worker 侧流量不可信”的模型修正；托管 Kubernetes 厂商对默认安全策略的审计是否成为行业标配；OverlayFS 这类老本地提权漏洞在云主机上的真实风险敞口；以及 Valkey CVE-2026-25243 的修复窗口。对租户而言，把“平台方是否有公开安全公告、是否有悬赏与渗透测试机制”写进选型问卷，可能是这次事件最实用的后续动作。
（信息来源：卡巴斯基 Securelist 技术复盘 2026-10-27、SAS 2026 演讲、Mirantis 安全公告 GHSA-3588-pcxv-rx45 及多家安全媒体交叉报道；具体版本与修复要求以官方公告为准。）
暂无评论内容