容器隔离的边界在哪里？常见的容器逃逸路径有哪些，如何加固？

直接回答：容器不是安全边界——它与宿主机共享内核，隔离靠 namespace（视图隔离）+ cgroup（资源隔离）+ capabilities/seccomp（权限收敛）。逃逸路径主要有：内核漏洞（Dirty Pipe 类，共享内核的宿命）、危险配置（privileged、挂载 docker.sock、hostPath 挂根目录）、capabilities 过大（CAP_SYS_ADMIN 近乎 root）、以及运行时自身漏洞（runc CVE）。加固的总原则：最小权限、只读、非 root、以及运行时监控。

展开解析：具体加固清单：镜像非 root 用户运行（runAsNonRoot）；drop ALL capabilities 再按需添加；readOnlyRootFilesystem 加显式 tmpfs；seccomp/AppArmor 限制系统调用；禁挂 docker.sock（等于宿主 root）。编排层用 Pod Security Standards（restricted 基线）和准入控制（OPA/Kyverno）强制。供应链侧：基础镜像最小化（distroless）、镜像扫描入 CI、签名验签。意识层面两条：其一，内核漏洞无法靠配置消除，及时升级宿主机内核是根本，高隔离需求场景用 Kata/gVisor 这类沙箱运行时换独立内核；其二，"容器逃逸"新闻里多数案例是配置错误而非 0day——先把基线配置做对，收益远大于追逐奇技。

追问方向：namespace 与 capability 的分工？gVisor 的拦截层原理？runtime 安全监控（Falco）检测什么？

（约 460 字）