容器安全上下文配置的核心是显式设定最小权限：必须设置runasuser≥10001、runasgroup、fsgroup，禁用allowprivilegeescalation，drop all capabilities后按需添加，启用readonlyrootfilesystem和runtimedefault seccomp，并通过opa等工具强制审计与准入控制。
配置系统服务运行时的安全上下文，核心是让容器在最小必要权限下运行，而不是“能跑就行”。真正有效的审计不是等出事再查日志，而是在部署前就堵住逃逸和越权路径。关键不在堆参数，而在理解每个配置项如何切断攻击链。
明确容器身份与权限边界
避免 UID/GID 冲突和隐式 root 权限是第一道防线。生产环境应强制使用高范围用户 ID（≥10001），且不依赖默认行为。
-
必须显式设置：
runAsUser: 10001、runAsGroup: 10001、fsGroup: 10001，不能只写runAsNonRoot: true - 禁用组 ID 继承：确保
runAsNonRoot生效前提下，runAsGroup和fsGroup也明确指定，防止挂载卷时因组权限失控导致写入宿主机敏感路径 - Bitnami 等加固镜像虽默认非 root，但若未覆盖
fsGroup，仍可能因 PVC 挂载继承节点组权限造成越权读写
切断特权升级与能力滥用路径
攻击者常利用能力残留或提权机制突破隔离。仅靠非 root 用户无法阻止 setuid 二进制或内核漏洞利用。
-
禁止提权：
allowPrivilegeEscalation: false是硬性要求，尤其在美国 VPS 等多租户环境中，该参数开启等于给攻击者留后门 -
能力裁剪优先 drop ALL：先
drop: ["ALL"]，再按需add，如仅开放NET_BIND_SERVICE（绑定 1024 以下端口）；避免保留CAP_SYS_ADMIN、CAP_DAC_OVERRIDE、CAP_NET_RAW - 注意
privileged: false必须显式声明——Kubernetes 默认为false，但 kube-score 等工具会将其列为 Critical 风险项，未声明即视为隐患
锁定文件系统与运行时行为
根文件系统可写、/proc 可读、seccomp 缺失，是逃逸攻击的三大温床。这些配置直接影响攻击者能否持久化、探测宿主机或注入恶意 syscall。
-
根目录只读：
readOnlyRootFilesystem: true，配合emptyDir或hostPath卷处理临时写入，杜绝篡改/bin、/etc等关键路径 -
启用 seccomp 默认策略：
seccompProfile: { type: "RuntimeDefault" }，拦截如ptrace、mount、clone等高危调用，美国 VPS 环境中尤其需防范 ptrace 注入 - 限制敏感路径暴露：对金融、医疗类容器，额外通过
securityContext禁用/proc挂载或设为只读，满足 CCPA/HIPAA 合规要求
嵌入自动化审计与持续验证
人工检查易遗漏，需将安全上下文纳入 CI/CD 和运行时防护闭环。
- CI 阶段用
kube-score扫描 YAML，重点检查privileged、readOnlyRootFilesystem、runAsUser范围、allowPrivilegeEscalation是否缺失或设错 - 集群准入层用 OPA/Gatekeeper 强制策略，例如拒绝所有未设置
runAsUser ≥ 10001的 Pod 创建请求 - 运行时结合 Defender for Containers 或 HSS 插件，监控异常 syscall（如非预期
unshare）、进程提权行为，实现逃逸实时阻断
