K8s 容器加 seccomp 默认档后怎么确认它真的生效、而不是被 runtime 静默忽略？

【背景】 我在给一套 K8s（1.29，containerd 1.7.x，节点 kernel 5.15）里的多语言服务做安全加固，目标之一是给所有业务容器叠加 seccomp 默认 profile，收窄系统调用面。我习惯从现象倒推根因，所以想先把"加固到底有没有真正落到运行时"这件事验证扎实，而不是只信配置文件。

【现象】

• 我在 Pod 的 securityContext 里设了 seccompProfile.type: RuntimeDefault，容器能正常起，业务功能看起来正常。
• 但我担心：有些 runtime/节点配置（比如 containerd 的 runtime 默认就忽略了 seccomp、或用了 runc 的旧配置、或 profile 被 override）会让这条配置"写了但没生效"，而表面完全看不出来。
• 我自己写了一个最小验证：在容器里跑一个故意触发被默认档屏蔽的 syscall（比如 unshare/clone3 之外的某些调用），看是否返回 EPERM，但目前结果不稳定，有时拦、有时没拦，我怀疑和具体 syscall 是否真在默认档黑名单里有关，而不是 seccomp 本身没生效。

【已尝试的排查与结果】

1. kubectl get pod -o yaml 确认 securityContext 已下发到 Pod spec——确认有这条字段。
2. 进容器跑 cat /proc/sys/kernel/seccomp/actions_avail，有 ALLOW/KILL/ERRNO/TRAP/TRACE，说明内核支持。
3. 用 docker run --security-opt seccomp=default.json 跑同样的探针，和节点上的行为对比，发现节点上更"宽松"。
4. 但还没找到一条能一锤定音、证明"当前这个容器里 seccomp 已加载且是 RuntimeDefault"的方法。

【期望得到的答案形态】 希望有人能给出可复现的验证手法，比如：

• 怎么从 /proc/<pid>/status 的 Seccomp 字段判断是 0（disabled）/1（strict）/2（filter）？
• 怎么导出并比对当前容器实际加载的 seccomp BPF 规则，确认它等于 docker 的 default.json 而不是空 profile？
• 有没有一个"一定会被默认档拦截"的可靠探针 syscall / 测试用例，避免我踩到"syscall 本来就不在黑名单里"的坑？
• containerd/runc 侧有哪些常见配置会让 seccomp 被静默忽略（比如 runtime 配置、seccomp 默认被关掉），分别在哪个文件/字段里能看出来？

如果能附上具体的命令、字段位置和判读标准就更好了。