防范容器逃逸的核心是权限最小化、运行时限制与纵深监控协同：禁用privileged模式，严格限制hostPath/hostPID等敏感挂载与共享，强制非root运行并裁剪CAP_SYS_ADMIN等高危能力，启用只读根文件系统，禁用自动挂载ServiceAccountToken，并叠加eBPF/LSM策略与安全容器运行时。
防范容器逃逸（Container Escape）的核心，是切断攻击者从容器突破隔离、触达宿主机的常见路径。不是靠单一配置，而是通过权限最小化、运行时限制和纵深监控三类措施协同落地。
禁用高危Pod配置
特权模式（
privileged: true
）是逃逸最直接的入口，必须全局禁止。同时需严格审查以下配置：
hostPath
挂载：禁止挂载
、
、
、
等敏感路径；确有需要时，应限定只读且路径精确到子目录（如
）
hostPID / hostIPC / hostNetwork
：除非极特殊场景（如网络插件或监控代理），一律设为
allowPrivilegeEscalation: true
：默认即为 true，必须显式设为
，防止容器内进程调用
提权
强制非 root 运行与能力裁剪
即使逃逸发生，低权限起点也能大幅压缩攻击面：
在
PodSecurityContext
中设置
，并搭配
（镜像中需真实存在该用户）
使用
移除默认继承的高危能力，至少包括：
、
、
、
、
启用
，阻止向容器根文件系统写入恶意二进制或配置
阻断凭证泄露与API滥用
逃逸后攻击者常依赖 ServiceAccount Token 或 Kubelet API 扩展权限：
禁用默认自动挂载：在 Pod 中设置
；仅对明确需要访问 API 的服务，绑定最小权限 RBAC Role 并单独挂载 token
限制 Kubelet API 访问：确保节点上 Kubelet 的
（关闭只读端口），且
、
启用
NodeRestriction
准入控制器（ACK 等托管集群默认开启），防止攻击者伪造节点身份篡改自身绑定的 Pod 资源
引入运行时防护层
基线配置无法覆盖所有未知漏洞，需叠加主动防御：
部署 eBPF 或 LSM（如 SELinux/AppArmor）策略，拦截异常系统调用（如
、
、
）
使用安全容器运行时（如
gVisor
或
Kata Containers
），通过独立内核或用户态内核实现强隔离
对关键目录（
、
、
）部署文件完整性监控（FIM），而非仅依赖静态扫描
//proc/var/run/docker.sock/sys/etc/configfalsefalseexecverunAsNonRoot: truerunAsUser: 1001capabilities.dropSYS_ADMINNET_ADMINSETUIDSETGIDRAWIOreadOnlyRootFilesystem: trueautomountServiceAccountToken: false--read-only-port=0--anonymous-auth=false--authorization-mode=Webhookmountchrootinit_module/etc/crontab/root/.ssh/authorized_keys/usr/bin/