nginx worker进程必须降权为专用非root用户（如nginx）运行，主进程以root启动绑定特权端口；需在nginx.conf全局块顶部配置user nginx nginx;，并创建无登录用户、收紧文件权限、验证ps进程身份、配合容器能力限制形成五层闭环防护。
让 Nginx Worker 进程以非 root 用户运行，是容器环境中最直接有效的提权防护手段。主进程仍需 root 绑定 80/443 端口，但所有实际处理请求、读取文件、写入日志的 Worker 必须降权——一旦 PHP 或 Nginx 自身存在 RCE 漏洞，攻击者拿到的只是低权限 shell，无法直接修改系统配置、加载内核模块或逃逸到宿主机。
创建专用运行用户并显式配置
不要依赖默认的 nobody（多服务共用、边界模糊）或未锁定的普通账户。执行：
- useradd -r -s /sbin/nologin nginx —— 创建无登录能力的系统用户
- 在 /etc/nginx/nginx.conf 全局块顶部添加：user nginx nginx;
- Dockerfile 中避免
USER root，改用USER 1001:1001（UID/GID 需与 host 一致） - 容器启动时加 --user 1001:1001，确保与配置中用户完全匹配
验证权限是否真正分离
仅改配置不等于生效，必须验证进程级权限落地：
- 执行 ps aux | grep nginx：应看到一行
root开头的 master process，其余多行必须是nginx（或你指定的用户名）开头的 worker process - 若全为 root，检查是否漏 reload（
nginx -s reload）或配置被 include 覆盖 - 若显示
nobody，说明配置未命中或用户不存在；用 id nginx 和 passwd -S nginx 确认账户状态（应为 LK 锁定）
同步收紧文件系统权限
Worker 用户权限再低，若能读取私钥、写入配置或遍历目录，仍可造成突破：
- 网站根目录（如
/var/www/html）设为 750，属主root，属组nginx；Worker 可读不可写 - SSL 私钥文件权限必须为 600，且仅
root可读；Nginx 主进程读取后，由 Worker 复用内存中的证书上下文 - 日志路径（
/var/log/nginx）属主设为root:nginx，目录权限 750；日志文件由 Worker 以 nginx 身份追加写入 - 在 server 块中启用 disable_symlinks on if_not_owner;，防止符号链接越权访问
配合容器运行时限制进一步收窄能力
即使降权，root 容器仍默认拥有大量内核 capabilities。在 docker run 或 pod spec 中加入：
-
--cap-drop=ALL —— 剥离全部能力，再按需添加必要项（如
CAP_NET_BIND_SERVICE） - --read-only + --tmpfs /var/cache/nginx:rw,size=10m —— 根文件系统只读，仅开放必要临时路径
- --security-opt no-new-privileges:true —— 阻止进程通过 execve 获得新权限
- 避免挂载宿主机敏感路径（如
/etc/passwd、/proc、/sys）
不复杂但容易忽略：worker 降权不是单点配置，而是用户创建、配置声明、进程验证、文件权限、容器能力五层闭环。缺一环，风险就可能回流。
