建立容器节点运行时基线

容器节点的运行时基线，不应只记录 Kubernetes 版本或业务镜像信息。真正决定容器隔离边界的，是节点实际调用的底层运行时，尤其是 runC 的版本、上层运行时来源、挂载策略、权限配置以及 LSM 状态。以 CVE-2025-52881 为例，攻击者可能利用竞态条件和共享挂载，干扰 runC 对 /proc/self/attr/ 的写入，使原本用于设置安全标签的操作被重定向到其他 procfs 接口。节点基线如果缺少这些信息，漏洞影响就难以准确判断。

基线应记录什么

版本基线必须以“节点实际执行的版本”为准，而不是软件仓库中的可用版本，也不能只查看客户端或业务容器镜像。应逐节点确认 runC 的版本及其安装来源，并关联 containerd、CRI-O 或 Docker 等上层运行时。对于该漏洞，需重点识别 runC 1.2.7、1.3.2 和 1.4.0-rc.2；对应修复版本分别为 1.2.8、1.3.3 和 1.4.0-rc.3。

配置基线则应覆盖影响边界的关键项：是否存在特权容器，是否授予过多 linux capabilities，是否共享宿主机目录、进程命名空间或可变挂载结构，以及是否允许不可信用户提交自定义构建任务。共享挂载并不只是一个普通的存储配置，它可能改变路径解析条件，应记录其来源、读写属性、生命周期和使用者范围。

把基线变成持续核验

节点还应记录 LSM 的预期状态，并确认容器进程能够获得正确的安全标签。/proc/sysrq-trigger 和 core_pattern 等敏感 procfs 接口应纳入保护清单，既要检查是否存在直接写入路径，也要关注通过挂载和运行时操作形成的间接影响。对无法确认实际 runC 版本的节点，应按未修复处理，直到完成节点级验证。

基线的价值不在于生成一份静态清单，而在于支持变更后的判断。节点升级、运行时替换、构建任务调整或共享挂载变化后，应重新核对版本、权限、挂载和 LSM 状态。发现标签设置失败、敏感配置异常变化、运行时错误或节点无明显原因重启时，应先隔离节点并保存运行时、内核和审计信息，而不是只删除相关 Pod。