pod级runasnonroot未生效因镜像默认以root启动且未声明user；需在dockerfile中添加user指令，或临时用runasuser配合runasnonroot:false（不推荐）。
Pod 级 SecurityContext 中 runAsNonRoot 为什么没生效？
常见现象是 Pod 一直 Pending，Events 显示 container has runAsNonRoot and image will not run as non-root。根本原因不是配置写错了，而是镜像默认以 root 用户启动，且未在 Dockerfile 中显式声明非 root 用户或设置 USER 指令。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先确认镜像实际启动用户：
docker inspect <image> | jq '.[0].Config.User'</image>，空值或"0"都会导致失败 -
runAsNonRoot: true是强制校验，K8s 不会帮你降权，只做运行前检查 - 若无法改镜像，可临时用
runAsUser: 65534（nobody）绕过，但需同步加runAsNonRoot: false—— 这本质是放弃校验，不推荐生产用 - 真正安全的做法是在
Dockerfile末尾加USER 1001:1001，并确保该 UID 在容器内有权限访问所需路径
容器级 securityContext 覆盖 Pod 级时的参数优先级
K8s 的覆盖规则很直接：容器级字段永远优先于 Pod 级。但容易忽略的是，**部分字段不支持“继承+覆盖”，而是完全替换**。比如 capabilities 就是全量覆盖，不是合并。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Pod 级设了
add: ["NET_ADMIN"]，容器级又只写add: ["SYS_TIME"]→ 最终只有SYS_TIME，NET_ADMIN消失 - 要保留能力叠加，必须在容器级显式重复声明：
add: ["NET_ADMIN", "SYS_TIME"] -
readOnlyRootFilesystem和allowPrivilegeEscalation是布尔值，容器级直接覆盖，无合并逻辑 - 调试时用
kubectl get pod <name> -o yaml</name>看最终生效的 spec，别只信自己写的 YAML
seccompProfile 在不同 K8s 版本中的路径写法差异
1.19+ 支持 RuntimeDefault，但老版本不认；自定义 profile 路径则依赖节点上 /var/lib/kubelet/seccomp/ 是否存在对应文件 —— 这个路径不能写错，也不能靠 configmap 挂载后自动识别。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- K8s ≥ 1.19：优先用
type: RuntimeDefault，无需挂载 profile，兼容性好 - 自定义 profile 必须提前分发到每个 Node 的
/var/lib/kubelet/seccomp/<profile-name>.json</profile-name>，kubelet 启动时才加载 - 路径写成
localhost/profiles/hardened.json，不是绝对路径，也不是 URL；localhost是固定前缀，不可省略或改成其他字符串 - 用
kubectl exec进容器后执行cat /proc/1/status | grep Seccomp，输出2表示生效，0表示未启用
为什么加了 privileged: true 还被 SELinux 拦住？
Privileged 容器在 Linux 层面确实获得全部 capabilities，但若节点启用了 SELinux（如 RHEL/CentOS 默认），它仍会按策略拦截某些系统调用，比如 mount 或访问 /sys/fs/cgroup。这时候看日志不是 K8s Event，而是 dmesg 或 journalctl -t setroubleshoot。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先确认节点 SELinux 状态：
getenforce，如果是Enforcing，privileged 不等于“完全自由” - 临时调试可设
seLinuxOptions: { level: "s0:c123,c456" }（需匹配节点 MLS 级别），但更稳妥是给容器打上合适 type，比如container_t - 生产环境别关 SELinux，而是用
audit2allow分析拒绝日志，生成自定义策略模块并加载 - 注意：
privileged: true会自动禁用 seccomp、AppArmor、Capabilities 限制，但对 SELinux 无影响 —— 这点常被误认为“全开了就没事了”
真正麻烦的从来不是写对 YAML，而是节点上实际运行时的权限模型叠加：Linux capabilities + SELinux/AppArmor + seccomp + user namespace。改一个字段，可能只解决表层报错，底下还有两层拦截等着你。
