直接查看容器内/proc/1/status中的capeff字段，用capsh --decode解码后重点检查cap_sys_admin、cap_sys_ptrace等高危能力；docker run中--cap-add=sys_admin、--cap-add=all、--security-opt seccomp=unconfined、--userns=host等参数均可能引入逃逸风险，尤其cap_sys_admin单独存在且未隔离user namespace时即构成严重威胁。
怎么看容器有没有危险的 Capabilities
直接进容器执行 cat /proc/1/status | grep CapEff，拿到的是十六进制的 capability 位掩码（比如 0000003fffffffff）。这个值本身没法读，得解码。如果容器里装了 capsh，就用 capsh --decode=0000003fffffffff；没装的话，可以拷出来在宿主机上解，或者用在线工具（注意别传敏感环境）。重点盯 CAP_SYS_ADMIN、CAP_SYS_PTRACE、CAP_NET_ADMIN、CAP_DAC_READ_SEARCH 这几个——尤其是前两个，基本等于给了逃逸钥匙。
docker run 启动时哪些参数会悄悄加特权
很多人以为没加 --privileged 就安全了，其实不然。以下命令都可能引入高危 capability：
-
docker run --cap-add=SYS_ADMIN—— 明确添加，最危险 -
docker run --cap-add=ALL—— 看似方便，实则等同于--privileged的能力子集 -
docker run --security-opt seccomp=unconfined—— 绕过 seccomp 过滤，让CAP_SYS_ADMIN更容易被利用 -
docker run --userns=host—— 关闭 user namespace 重映射，使CAP_SYS_ADMIN直接生效，无需额外提权步骤
这些参数常出现在 CI/CD 脚本或旧版 Helm chart 中，容易被忽略。
为什么 CAP_SYS_ADMIN 单独出现就足够危险
CAP_SYS_ADMIN 不是普通 capability，它覆盖 mount、umount、pivot_root、setns、clone with CLONE_NEWNS 等大量系统调用。只要它存在，且没启用 user namespace 隔离，攻击者就能：
- 执行
mount -t proc proc /proc强行挂载宿主机 proc（若已挂载/proc则跳过） - 用
nsenter -m -t 1 -- /bin/sh进入 init 进程的 mount namespace（前提是 PID namespace 未隔离） - 构造 cgroup v1 release_agent 触发宿主机 root 执行任意命令（需写入 cgroup 目录权限）
- 加载恶意内核模块（若有
CAP_SYS_MODULE，但CAP_SYS_ADMIN已隐含部分模块控制能力）
它不像 CAP_NET_BIND_SERVICE 那样只影响单一功能，而是一个“元权限”——很多逃逸链的起点就卡在这里。
Kubernetes 中怎么快速定位高危 Pod
在集群中搜 CAP_SYS_ADMIN 类配置，不能只看 securityContext.capabilities.add，还要检查组合条件：
- 运行
kubectl get pods -A -o wide --field-selector 'status.phase=Running' | while read ns pod rest; do kubectl get pod -n "$ns" "$pod" -o jsonpath='{.spec.containers[*].securityContext.capabilities.add}{"\t"}{.spec.hostPID}{"\t"}{.spec.securityContext.runAsUser}{"\t"}{.spec.securityContext.seccompProfile.type}{"\n"}'; done | grep -i 'sys_admin\|hostpid\|0' - 重点关注：
runAsUser: 0+hostPID: true+add: [SYS_ADMIN]的三连配置，这种组合下逃逸成功率极高 - seccomp profile 是
unconfined或为空，也会放大CAP_SYS_ADMIN的危害
真正难排查的不是明面上的 --cap-add，而是通过自定义 runtimeClass、PodSecurityPolicy（已弃用但存量仍在）、或 admission webhook 动态注入 capability 的情况——这类必须查 audit log 或 admission controller 日志。
