最有效做法是直接禁用sudo并彻底清理SUID/SGID权限位，同时以非root用户运行容器。具体包括：构建时删除sudo二进制文件；用find+chmod清除所有SUID/SGID位；创建专用非特权用户（如UID 1001）并通过USER指令锁定运行身份；运行时通过-u或securityContext强制非root上下文，实现三重防护。
直接禁用 sudo 是最有效的做法——容器里根本不需要它。微服务容器应当只做一件事，且以最小权限运行，sudo 不仅违背这一原则，还可能成为提权攻击的跳板。
从镜像构建阶段彻底移除 sudo 二进制文件
基础镜像（如 Ubuntu、Debian）默认自带 sudo，但绝大多数微服务应用完全用不到。在 Dockerfile 中显式删除它，比“不安装”更可靠，因为有些包依赖会悄悄带入：
- 使用 RUN apt-get purge -y sudo && rm -rf /var/lib/apt/lists/*（Debian/Ubuntu 系）
- 使用 RUN yum remove -y sudo && rm -rf /var/cache/yum（CentOS/RHEL 系）
- 构建后验证：在镜像中执行 which sudo 或 ls -l /usr/bin/sudo，应返回空或报错
清除残留的 SUID 权限位，阻断提权路径
即使删了 sudo，若镜像中仍存在其他带 SUID 的程序（如 /bin/mount、/usr/bin/passwd），攻击者仍可利用它们绕过限制。务必在构建末期清理：
- 添加一步：RUN find /usr/bin /bin -perm -4000 -type f -exec chmod u-s {} \; 2>/dev/null
- 同理清理 SGID：find /usr/bin /bin -perm -2000 -type f -exec chmod g-s {} \; 2>/dev/null
- 推荐在多阶段构建的 final 阶段执行，避免污染构建缓存
用非 root 用户运行，让 sudo 失去生效前提
sudo 的本质是“普通用户临时获得 root 权限”。只要容器内进程根本不以普通用户身份启动，而是直接以专用非特权用户运行，sudo 就完全无用武之地：
- 创建 UID ≥1001 的专用用户，例如：RUN addgroup -g 1001 -r appgroup && adduser -S -u 1001 -u 1001 appuser
- 所有应用文件用 COPY --chown=appuser:appgroup 赋权
- 严格使用 USER appuser:appgroup 切换上下文，且该指令必须出现在 CMD 之前
- 此时即使误留 sudo，它也无法提权到 root（因为容器内没有 root 用户上下文，且 USER 指令已锁定运行身份）
运行时加固：双重保险防止意外回退
即便镜像层做到位，也要防住运行时被覆盖。在 docker run 或 Kubernetes 中强制约束：
- 命令行启动时加 -u 1001:1001，覆盖镜像内任何 USER 设置
- Kubernetes Pod 中配置：securityContext.runAsNonRoot: true 和 runAsUser: 1001
- 配合 securityContext.seccompProfile.type: RuntimeDefault，拦截 execve 等敏感系统调用
