Golang应用在K8s中的Pod安全上下文(SecurityContext)配置

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。改一个字段，可能只解决表层报错，底下还有两层拦截等着你。