配置性逃逸：边界从未真正建立#

特权容器、宿主 PID/网络空间、敏感目录挂载和过宽 Capability，会让容器直接获得宿主能力。这类问题不需要利用漏洞，攻击者只是在使用已经配置的权限。

防线是最小权限、只读挂载、Capability 白名单和 User Namespace。User Namespace 将容器内 UID 0 映射为宿主无特权 UID，避免容器 Root 天然等于宿主 Root；但它需要显式开启。

运行时漏洞：边界实现被绕过#

runc、containerd、镜像解包器和管理 API 都属于隔离链的一部分。CVE-2019-5736 一类问题说明，即使容器配置合理，运行时处理进程、文件或镜像时仍可能暴露宿主执行路径。

防线包括及时升级、缩小运行时权限、分离镜像构建与执行、限制管理 Socket，并让节点可替换。这里的重点不是再加一条容器内规则，而是减少高权限运行时组件的攻击面。

内核漏洞：共享边界本身失效#

容器共享宿主内核。Dirty COW、Dirty Pipe 等漏洞利用内核内存或页缓存实现缺陷，namespace 和 cgroup 无法修复内核代码本身。

防线是内核修补、Seccomp、LSM、User Namespace，以及在高风险场景提高隔离层级。gVisor 减少直接进入宿主内核的系统调用，microVM 则使用独立 Guest Kernel，代价是兼容、启动和资源成本。

我的判断：先识别根因，再选择隔离#

我会分别检查：

1. 配置是否已经越权；
2. 运行时与管理面是否暴露高权限入口；
3. 威胁模型能否接受共享宿主内核。

这三项不能互相替代。修补内核不能纠正特权挂载，使用 microVM 也不能消除管理 API 的错误授权。内部受控任务可以通过容器加固承担共享内核风险；不可信代码接触高价值数据时，应考虑 gVisor 或 microVM，并继续保留配置与运行时防线。