Windows 节点 SMB 出站流量审计策略

CVE-2026-76654 暴露的路径值得单独拎出来看：Windows 节点上的 kubelet 在解析 subPath 时，可能对卷内的符号链接目标发起认证，把节点的 NetNTLMv2 哈希送往外部 SMB 共享。这条链路上真正难处理的地方不在漏洞本身，而在于它产生的流量天然落在多数团队的审计盲区里——kubelet 是节点上的主机进程，Pod 级 NetworkPolicy 约束不到它，容器侧的可观测性也看不见它。

先把审计范围收敛下来

全量抓取节点出站流量既不现实也没有必要。合理的顺序是先框定对象：筛出调度到 Windows 节点、且 volumeMounts 使用了非空 subPath 的工作负载，再回看每个条目对应的卷类型。hostPath、可写 PVC、从共享目录同步而来的卷，优先级明显高于只读的 ConfigMap 与 Secret 投射。链接对象来自卷内容，而不是 subPath 配置本身，因此“卷是否可写、由谁写入”这一项决定了审计的密度。清单出来之后，审计才有明确的观察对象，而不是对着出口流量做无差别排查。

三个取证面要交叉

单一来源很难把“疑似”变成“确认”。主机侧看 Windows 防火墙日志与当前出站规则，确认是否存在指向 445 的放行；认证侧看安全日志中的登录类型 3 事件与 SMB 客户端事件，重点辨认发起方的进程上下文；网络侧看出口网关的会话记录，确认有没有新的、非业务预期的 SMB 外联。三者对得上，才谈得上是证据；只有网关报表里出现一条连接，可能只是某台节点的正常备份任务。

阻断和审计需要分开对待。用主机防火墙封掉出站 445 能显著压缩凭据外泄的实际影响，但它是缓解措施，不构成修复，也不能代替审计。执行前必须评估依赖：使用 SMB CSI、Azure Files、自建 Samba 共享，或依赖 445 的备份与日志采集组件的节点，直接阻断会造成挂载失败或采集中断。可行的做法是按节点池分批启用，并在启用前后对比挂载成功率与业务探针。

审计策略真正的价值，是把它变成常态而非一次性动作。Windows 节点上 kubelet 进程的出站连接、NTLM 认证事件、SMB 客户端错误集中的节点、新增使用 subPath 的工作负载，这四类观察点纳入日常监控后，同类变体在下一次出现时才有机会被提前看到。复盘时顺带回答两个问题：哪些工作负载确实需要 subPath，哪些卷本不该可写。这两问的答案，往往比升级版本更能压低长期风险。