subPath 在 Windows 上的解析机制

subPath 的用法大家基本都熟：卷像一整个包裹，subPath 只取里面的一份塞进容器。在 linux 上这多半是件安静的事，到了 Windows 节点上，这条取件路径多出几个岔口。

Windows 的路径不一定指向本机磁盘，也可以直接指向网络共享。而 Windows 有个老习惯：只要访问的是网络路径，系统就会主动拿本机账户去发起认证，过程默认发生，界面上不会问一句“要不要发”。这个习惯本身没什么问题，可放到 kubelet 身上就变味了——kubelet 是节点上的主机进程，用的是节点自己的身份。

这么一来，整条链路就清楚了：Pod 的 subPath 指向卷里一个精心构造的符号链接或重解析点，kubelet 去解析这个路径，跟着链接一路走到外部 SMB 共享，认证信息（也就是 NetNTLMv2 哈希）便顺手递了出去。CVE-2026-76654 讲的就是这一段。

要说明白的是，subPath 本身不制造链接。它只是“取件指令”，链接是本来就躺在卷里的。所以风险并不取决于有没有配 subPath，关键在于这个卷有没有被人塞东西的入口：来自可写共享、由不可信流程同步，或者工作负载自己对卷有写权限，这类就得打上重点标记。

还有两处容易误解。一是别指望网络策略：kubelet 是主机进程，Pod 级的规则管不到它，拦截点得放在主机防火墙或集群出口那一层。二是别把范围放大：只有能被调度到 Windows 节点、并且确实用了非空 subPath 的工作负载才算在内，linux 节点的行为差异不在这个话题里。

说到底，这是挂载配置叠加节点出口边界的问题，并不等于“集群随时会被远程打穿”。从旁观者的角度看，值得记住一句朴素的话：路径解析会跟着链接走，而 Windows 访问网络路径时会主动亮明身份。想少踩坑，就先去看卷里有没有不该存在的写入入口，再看节点能不能随随便便连出去。