核心是全链路最小权限：镜像层用固定UID创建用户并--chown赋权，运行时禁用提权与能力，K8s层用securityContext强制runAsNonRoot和readOnlyRootFilesystem，配套反向代理与日志采集消除root依赖。

容器化集群中贯彻非 root 运行，核心不是“能不能切用户”，而是把最小权限从镜像构建、运行时配置到编排层全部串起来。关键在于每一环都拒绝默认 root，不依赖单点补救。

镜像构建阶段：显式创建低权限用户并设为默认运行身份

不能只靠 USER node 这类模糊写法——node 用户在不同基础镜像中 UID 可能是 0（如某些旧版 Node 镜像），也不具备确定性。应统一用数字 UID 创建专用用户：

• 使用 RUN adduser -u 1001 -D appuser 显式指定 UID，避免组名或用户名歧义
• 用 COPY --chown=appuser:appuser 直接赋权应用文件，不依赖后续 chown
• WORKDIR /app 和 USER 1001 必须成对出现，且位于所有 COPY 和 RUN 之后
• 避免在 USER 指令后执行任何需要 root 的操作（如安装系统包、修改 /etc）

容器运行时：禁用提权能力，强制非 root 上下文

Docker 或 containerd 默认允许容器内进程尝试提权。必须通过运行参数主动关闭：

• 添加 --security-opt=no-new-privileges，阻止 setuid/setgid 程序生效
• 使用 --cap-drop=ALL 移除全部 Linux capabilities，再按需加回必要项（如 --cap-add=NET_BIND_SERVICE 仅用于绑定 80/443）
• 挂载敏感路径（如 /proc、/sys）时加 :ro 后缀，防止篡改主机状态
• 启用 --read-only 根文件系统，并用 --tmpfs /tmp --tmpfs /run 提供必要可写空间

Kubernetes 编排层：用 SecurityContext 做强制兜底

不能假设所有镜像都已合规。K8s 的 securityContext 是最后一道防线，必须声明式锁定：

• runAsNonRoot: true —— 若容器启动用户是 root，Pod 直接失败，不给机会
• runAsUser: 1001 —— 强制以指定 UID 运行，覆盖镜像内 USER 指令
• readOnlyRootFilesystem: true —— 根目录只读，杜绝恶意持久化
• allowPrivilegeEscalation: false —— 关闭 fork/exec 提权路径，比 no-new-privileges 更严格
• 配合 capabilities.drop: ["ALL"] 在容器级做能力裁剪

配套机制：让非 root 运行不成为运维负担

开发者常因端口、日志、健康检查等“便利性”倒退回 root。需配套解决：

• 应用监听 3000/8080 等非特权端口，前端用 Ingress Controller（如 Nginx、Traefik）代理 80/443 流量
• 日志统一输出到 stdout/stderr，由集群日志采集器（Fluentd、Loki）收集，不写本地文件
• 健康检查探针（liveness/readiness）用 HTTP GET，避免 exec 探针调用需要权限的命令
• 敏感配置通过 Secret 挂载，不进镜像；临时密钥用 ServiceAccountToken 卷自动注入