容器逃逸指攻击者从容器内部突破隔离边界，影响宿主机或其他工作负载。它通常不是单一配置导致的结果，而是漏洞、过高权限、敏感挂载、内核暴露和集群权限叠加后的链式风险。防护容器逃逸不能只依赖某个安全产品，也不能只在镜像扫描阶段完成，而要覆盖构建、部署、运行、节点和应急响应全链路。
先理解逃逸攻击面的组成
容器隔离主要依赖Linux内核能力，包括Namespace、cgroup、Capabilities、seccomp和安全模块。只要容器仍共享宿主机内核，就必须承认隔离不是绝对边界。攻击者可能先利用应用漏洞进入容器，再寻找可写HostPath、Docker socket、特权模式、危险Capabilities、内核漏洞或高权限ServiceAccount，逐步扩大权限。
常见高风险入口包括挂载/var/run/docker.sock、以特权模式运行、共享宿主机PID命名空间、把宿主机根目录挂入容器、允许容器加载内核模块、运行过旧内核或容器运行时。每一项单独看都可能有业务理由，但组合起来就会显著提高逃逸概率。对容器安全体系的整体理解，可参考 https://www.cloudnative-tech.com/container_security/ 。
镜像与应用层：减少初始入侵机会
逃逸防护的第一层是减少攻击者进入容器的机会。镜像应来自可信仓库，基础镜像定期更新，构建过程固定依赖版本，避免把调试工具、包管理缓存、密钥和构建凭据带入运行镜像。应用层应及时修复远程代码执行、文件上传、模板注入和反序列化等高危漏洞。
镜像不是越小越安全，但更小的运行镜像通常意味着更少工具和更少攻击面。对于Java、Go、Node.js等应用，可以采用多阶段构建，把编译器和调试工具留在构建阶段。对于需要Shell的运维场景，不应因此让所有业务镜像都携带完整工具链，而应通过受控调试流程处理。
运行时配置：把可利用权限降下来
运行时加固的重点是最小权限。容器应默认非root运行、关闭特权模式、禁止权限提升、丢弃不必要的Capabilities、启用默认seccomp，并尽可能使用只读根文件系统。对高风险字段要建立准入规则，例如HostPath、hostPID、hostNetwork和特权容器必须经过审批。
securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
seccompProfile:
type: RuntimeDefault
capabilities:
drop:
- ALL这类配置不能完全消除未知漏洞，但能显著压缩漏洞被利用后的操作空间。即使攻击者获得应用进程权限，也难以直接写入系统目录、调用敏感系统能力或通过默认能力继续提权。
宿主机与Kubernetes层面的边界
节点层是容器逃逸防护的关键。应保持内核、containerd、runc、Kubelet和节点系统组件及时更新；限制节点SSH入口；避免把控制面组件和普通业务混部；对高风险工作负载使用专用节点池。节点上不应暴露不必要的容器运行时接口，尤其不能把Docker或containerd管理socket挂给业务容器。
Kubernetes层面要关注ServiceAccount和RBAC。很多逃逸链路并不是直接获得宿主机root，而是先读取Pod内Token，再访问API Server获取更多信息或创建高权限工作负载。因此普通业务应使用最小权限账号，能不挂载Token就关闭自动挂载：
spec:
automountServiceAccountToken: false如果应用确实需要访问API Server，也应创建专用ServiceAccount，只授予必要资源和动词。命名空间、网络策略、资源配额和Pod安全策略应共同发挥作用，避免一个容器被入侵后快速影响整组服务。
监控与响应：发现异常比想象更重要
逃逸攻击通常会留下行为痕迹，例如容器内访问宿主机敏感路径、执行异常系统调用、扫描集群服务、读取服务账号Token、启动反弹Shell、下载未知二进制文件或尝试写入运行时Socket。运行时安全监控可以基于进程、文件、网络和系统调用建立规则，但规则应结合业务基线，避免过多误报。
响应流程需要提前准备。发现疑似逃逸时，不要只删除Pod，还应隔离节点、保留现场、导出相关日志、检查同节点工作负载、轮换可能泄露的Token和密钥。若节点级别已被影响，通常需要重建节点而不是简单重启服务。容器平台应具备快速驱逐、节点下线、镜像回滚和审计追踪能力。
常见问题
使用Kubernetes就能避免容器逃逸吗？
不能。Kubernetes提供编排和部分安全控制能力，但底层仍依赖Linux内核与容器运行时。若工作负载以特权模式运行、挂载宿主机敏感目录、使用过高RBAC权限或节点版本长期不更新，Kubernetes本身不会自动消除风险。正确做法是把Kubernetes安全上下文、准入策略、节点补丁和运行时监控组合起来，形成多层防护。
seccomp、AppArmor、SELinux需要全部启用吗？
应根据发行版、运行时和运维能力选择可持续方案。RuntimeDefault seccomp通常是较低成本的起点，可以阻断一批不常用或高风险系统调用。AppArmor和SELinux能提供更细粒度的强制访问控制，但需要策略维护能力。不要为了追求“全部启用”而上线无法解释和维护的策略，否则容易在故障时被整体关闭。
发现容器被入侵后，删除Pod是否足够？
通常不够。删除Pod只能清理当前实例，不能确认攻击者是否读取了Token、写入了持久化卷、影响了同节点其他容器或触碰了宿主机。应同时检查镜像来源、入口漏洞、运行时配置、节点日志、API Server审计日志和网络连接记录。对于疑似逃逸或节点被改动的情况，应隔离并重建节点，轮换相关凭据，再恢复业务。
结论
容器逃逸防护的核心是分层降低攻击成功率和影响范围。镜像层减少入口，运行时层降低可利用权限，节点层保持隔离基础可信，Kubernetes层限制横向扩散，监控响应层负责及时发现和处置。只有把这些措施纳入日常交付流程，容器安全加固才不会停留在一次性检查。
转载请注明出处：https://www.cloudnative-tech.com/p/7411/
