最稳妥的权限控制组合是dockerfile的user指令与k8s securitycontext双重锁定：需在镜像中显式创建固定uid非root用户、归属应用文件、清除root入口；k8s层则必须配置runasuser、runasgroup、fsgroup和allowprivilegeescalation四个字段，并校验uid/gid映射、端口绑定及日志路径可写性，再通过podsecurity admission兜底 enforce baseline策略。
直接用 Dockerfile 的 USER 指令 + Kubernetes 的 securityContext 双重锁定运行身份，是当前生产环境最稳妥的权限控制组合。单靠一方容易被绕过——比如镜像里写了 USER 1001，但 K8s 层没限制 runAsUser，攻击者仍可通过 securityContext 覆盖为 0；反之，若只在 K8s 配置了 runAsUser: 1001，但镜像内没创建该用户或文件属主仍是 root，容器启动就会失败或权限错乱。
Dockerfile 中 USER 指令必须做三件事
不是简单写一行 USER appuser 就完事，关键在构建阶段就夯实基础：
-
显式创建 UID 固定的非 root 用户：避免依赖基础镜像默认用户（如 Alpine 的 nobody UID 65534、Ubuntu 的 daemon UID 1），统一用 1001–65535 范围内的确定 UID，例如：
RUN groupadd -g 1001 appgroup && useradd -u 1001 -r -g appgroup -s /sbin/nologin appuser -
所有应用文件归属该用户：用
COPY --chown=appuser:appgroup或RUN chown -R appuser:appgroup /app，确保进程有读取和执行权限，且不会因挂载卷时权限不匹配导致启动失败 -
禁止镜像内保留 root 权限入口：删掉
sudo、su、passwd等二进制文件，或至少确保/etc/sudoers为空；不安装curl、wget等可能被用于下载恶意载荷的工具（除非业务强依赖）
K8s securityContext 必须覆盖四个核心字段
仅设 runAsUser 不够，需与镜像内用户对齐并补全运行时约束：
-
runAsUser: 1001：强制容器进程以 UID 1001 启动，必须与 Dockerfile 中创建的 UID 完全一致；K8s 不会自动创建该用户，只做身份切换 -
runAsGroup: 1001：明确 GID，避免组权限继承混乱；若镜像中用户属于独立组（如上例的 appgroup），此处应填 1001 而非 0 -
fsGroup: 2001：专用于挂载卷（如 ConfigMap、Secret、PersistentVolume）的组 ID，建议设为与运行组不同的独立 GID（如 2001），防止容器意外修改其他 Pod 挂载的卷 -
allowPrivilegeEscalation: false：禁用通过setuid/setgid二进制文件提权，配合capabilities: drop: ["ALL"]彻底剥离内核能力
必须校验的三个运行时一致性点
配置写完不等于生效，上线前务必验证以下三点是否全部满足：
-
UID/GID 映射无冲突：检查宿主机挂载路径（如
hostPath）的目录权限是否允许 UID 1001/GID 2001 读写；若宿主机未创建对应用户，需用chmod 775 /path+chgrp 2001 /path手动授权 -
端口绑定不报错：非 root 用户无法绑定 1–1023 端口，若应用必须监听 80，应在容器内改用 8080，再通过 Service 的
targetPort: 8080和 Ingress 暴露；或用capabilities: add: ["NET_BIND_SERVICE"]授予单一能力（比用 root 安全得多） -
日志和临时文件可写入：确认
/tmp、/var/log等路径对 UID 1001 可写；推荐在 Dockerfile 中提前RUN mkdir -p /var/log/app && chown appuser:appgroup /var/log/app
进阶防护：用 PodSecurityPolicy 或 PodSecurity Admission 控制兜底
即使开发人员忘了配 securityContext，集群也应拒绝特权容器启动：
- 启用 PSP（已弃用但部分旧集群仍在用）：定义
runAsUser: rule: MustRunAsNonRoot，强制所有 Pod 使用非 root 用户 - 迁移到 PodSecurity Admission（K8s 1.23+ 默认启用）：在命名空间打标签
pod-security.kubernetes.io/enforce: baseline，自动拦截runAsUser: 0、privileged: true等高风险配置 - 结合 Opa/Gatekeeper 编写策略，例如：当
securityContext.runAsUser存在但镜像中未声明对应用户时，直接拒绝创建 Pod
