防范容器逃逸的关键是让容器本身无法获得突破隔离所需的权限起点：强制非root运行（runasnonroot: true + runasuser）、禁用提权（allowprivilegeescalation: false）、裁剪高危能力（capabilities.drop: ["all"]）、只读根文件系统（readonlyrootfilesystem: true），并禁用privileged、hostpath等危险配置。
防范容器逃逸的关键不是“加固系统服务”，而是**让容器本身无法获得突破隔离所需的权限起点**。系统服务（如 kubelet、containerd、dockerd）本身需保持可信和最小化暴露，但真正承载业务的容器才是攻击入口。安全上下文（SecurityContext）是 Kubernetes 中专为容器设计的权限控制机制，必须在 Pod 或容器层级配置，而非系统服务进程上直接设置。
明确配置位置：只在 Pod/Container 级生效
SecurityContext 是 Kubernetes API 的声明式字段，只能写在 Pod 或 container spec 中。它不作用于 kubelet、containerd 这类守护进程——这些组件应通过操作系统级加固（如 systemd 服务限制、seccomp profile、AppArmor 域）来保护，但它们不是“运行容器的安全上下文”。
- ✅ 正确位置：Pod YAML 的 spec.securityContext（影响所有容器）或 spec.containers[].securityContext（单容器覆盖）
- ❌ 错误理解：给 kubelet 进程加 SecurityContext，或试图在 /etc/systemd/system/kubelet.service 里写 runAsUser
核心字段配置要点（防逃逸直击路径）
以下字段组合能切断绝大多数逃逸链路，重点针对挂载逃逸、提权逃逸、内核能力滥用三类高发场景：
-
runAsNonRoot: true + runAsUser: 1001：强制非 root 启动，且指定真实存在的 UID。镜像中需提前创建该用户（如
RUN adduser -u 1001 -D appuser），避免 fallback 到 root - allowPrivilegeEscalation: false：禁用 execve 提权，堵住 setuid 二进制或内核漏洞利用后的权限跃迁
-
capabilities.drop: ["ALL"]，再按需 add：至少移除
SYS_ADMIN（挂载/umount）、NET_ADMIN（网络劫持）、SETUID/SETGID（用户切换）、RAWIO（设备直写） - readOnlyRootFilesystem: true：根文件系统只读，阻止写入恶意二进制、篡改 /etc/passwd 或注入 cron job
配套必须关闭的危险配置
仅设 SecurityContext 不够，必须同步禁用 Pod 中允许逃逸的“通道”：
- privileged: false（显式设为 false，不能省略）
-
hostPath 挂载：禁止
path: "/"、/proc、/sys、/var/run/docker.sock；若必须挂载，严格限定子路径 +readOnly: true - hostPID: false、hostIPC: false、hostNetwork: false：关闭命名空间共享，防止窥探宿主机进程或跨容器信号劫持
- automountServiceAccountToken: false：默认 token 不挂载，需访问 API 的服务单独绑定最小 RBAC 并显式挂载
运行时策略叠加（最后一道防线）
静态配置无法防御未知漏洞，需引入动态防护：
- seccompProfile: { type: RuntimeDefault }：启用 Kubernetes 默认 seccomp 策略，拦截 mount、chroot、init_module 等逃逸关键系统调用
- 节点级启用 AppArmor 或 SELinux：对容器进程施加 MAC 约束，例如禁止访问
/etc/shadow或执行ptrace - 生产环境建议使用 gVisor 或 Kata Containers：用独立内核或用户态内核替代共享宿主内核，从架构上隔离逃逸面
