如何逃出一个容器
容器被广泛用于隔离应用，但许多工程师认为不应把它们视为强安全边界，尤其是在运行不受信任代码时。评论者将共享内核的容器与虚拟机以及轻量级 VM（例如 Firecracker、Kata）进行对比，并指出容器逃逸通常依赖错误配置或为了方便而授予的额外 capabilities，例如访问 Docker socket 或 SYS_ADMIN。总体观点是，容器提供了有意义但并不完美的隔离，必须结合正确配置、宿主机补丁更新，以及在更高风险威胁模型下加入 gVisor 等额外层。
容器是安全边界吗？
- 线程中的分歧很大。
- 一方认为：容器“不是安全边界”，尤其不适合不受信任或多租户代码；它们共享宿主机内核，并暴露了较大的攻击面。
- 另一方认为：容器确实提供了真实的安全边界（namespaces、cgroups、seccomp、文件系统隔离），只是还不足以应对“运行任意不受信任代码”或 RCE-as-a-service 场景。
- 也有人强调需要细致区分：容器带来了有意义的隔离，但应被视为多层防护中的一层，而不是硬边界。
容器与虚拟机
- 许多评论指出：VM 是一种定性上更强的边界，因为它们不共享内核；攻击必须跨越一个更小、更可审计的接口（hypervisor + 设备驱动）。
- 容器是“共享内核隔离”；内核提权或 capabilities 滥用都可能导致逃逸。
- 文中还提到硬件特性，如 VM 上下文切换和缓存隔离，是 VM 相比容器在 Spectre/Meltdown 这类问题上的优势。
- 也有人提到轻量级 VM（Firecracker、Kata）和 gVisor 作为折中方案。
Capabilities、配置错误与现实风险
- 文章中的所有逃逸技术都需要额外权限：SYS_ADMIN、SYS_MODULE、SYS_PTRACE、DAC_READ_SEARCH、宿主机 PID 命名空间，或访问 docker.sock。
- 批评者指出这些默认并不会启用，因此文章展示的是“如何滥用错误配置”，而不是容器本身的固有缺陷。
- 其他人反驳称这类错误配置非常常见：工程师为了“让它能跑”而添加 capabilities、照搬糟糕教程，或者需要必须高权限的 profiling/监控工具。
- Docker 对 iptables 的操作以及默认暴露端口被提到是一个“footgun”，已经导致过真实事故。
内核漏洞与纵深防御
- 有人指出，“原生”容器如果使用默认 caps，通常只能通过内核本地提权漏洞（N-day 或 0-day）来逃逸。
- rootless 容器、用户命名空间以及 Podman 之类的工具可以缩小影响范围，但前提是配置正确。
- 形成的共识趋势是：容器能提升大多数普通服务器工作负载的安全性，但对于恶意多租户代码来说单独使用还不够；建议采用多层隔离。
杂项
- 还有一段跑题讨论了真实的海运集装箱以及它们有多难逃出，用作分层安全的类比。