Kubernetes Pod安全上下文核心是通过Pod级和容器级配置实现最小权限运行，必须设置runAsNonRoot、runAsUser、readOnlyRootFilesystem、allowPrivilegeEscalation及capabilities裁剪五项，覆盖用户身份、能力集、文件系统和提权控制，并需实测验证生效。
容器创建时设置安全上下文（Security Context），核心是让容器以最小权限运行，从用户身份、能力集、文件系统、提权控制等维度切断越权路径。这不只是加几个参数，而是对运行时行为的声明式约束。
明确配置层级：Pod 级与容器级要分清
安全上下文支持两种作用范围：
-
Pod 级（
spec.securityContext）：影响 Pod 内所有容器，适合统一策略，如默认用户组、卷属主（fsGroup） -
容器级（
spec.containers[*].securityContext）：只对该容器生效，优先级更高，适合差异化授权，比如仅某个容器需要NET_BIND_SERVICE
若两者同时设置同名字段（如 runAsUser），容器级会覆盖 Pod 级。建议通用规则放 Pod 级，特殊需求放容器级。
关键字段必须配齐
以下五项是提升隔离级别的基础配置，缺一不可：
-
runAsNonRoot: true：强制拒绝 UID=0 的进程启动，哪怕镜像默认用 root 也会失败——这是防逃逸的第一道闸 -
runAsUser: 1001（非零整数）：显式指定普通用户 UID，避免依赖镜像内未定义的 USER 指令 -
readOnlyRootFilesystem: true：根文件系统只读，防止恶意写入二进制或篡改配置；需提前把日志、临时目录挂为tmpfs或可写卷 -
allowPrivilegeEscalation: false：禁用suid/sgid提权、ptrace调试等常见提权手段 -
capabilities显式裁剪：用drop: ["ALL"]清空默认能力，再按需add，例如仅开放NET_BIND_SERVICE绑定特权端口
配合挂载与卷权限，避免权限错位
安全上下文不是孤立生效的，尤其涉及存储时：
- 设了
fsGroup: 2000，Kubernetes 会自动把挂载卷内文件属组改成 2000，但前提是卷本身允许 chgrp（如 emptyDir、hostPath 需宿主机目录属组可写） - 若用
hostPath或 NFS 卷，宿主机路径属主需匹配映射后的 UID/GID（启用 UserNS 时更要注意，容器 UID 0 实际对应宿主机 100000+） - 敏感配置（如证书、密钥）应通过
Secret挂载，而非直接复制进镜像或用 hostPath 暴露
验证是否真正生效
配置完别只看 YAML 是否通过校验，要进容器实测：
- 执行
id确认 UID/GID 是预期值，且无groups:中含 0（root 组） - 尝试
touch /etc/test应报错Read-only file system - 运行
cat /proc/1/status | grep CapEff查看生效的能力位图，确认没残留高危能力（如cap_sys_admin） - 检查
/proc/1/status中CapBnd和CapPrm字段，确保allowPrivilegeEscalation: false已反映在内核能力边界中
不复杂但容易忽略
