RUN 指令如何加固构建脚本防止恶意代码注入

RUN指令本身不执行用户输入，但作为构建阶段执行Shell命令的入口，若拼接不可信内容（如环境变量、构建参数）则可能触发命令注入；加固关键在于切断注入路径，确保其仅运行确定、静态、最小权限的命令。

RUN 指令本身不执行用户输入，但它是构建阶段执行 Shell 命令的入口，一旦命令中拼接了不可信内容（如环境变量、构建参数、外部脚本输出），就可能触发命令注入。加固的关键不是“防 RUN”，而是切断注入路径——让 RUN 只运行确定、静态、最小权限的命令。

避免动态拼接，禁用 shell 解析

Shell 形式（RUN apt-get update && ...）依赖 /bin/sh 解析，存在变量展开、通配符匹配、命令替换等隐式执行风险。只要涉及任何外部输入（哪怕只是 $BUILD_ARG），就应切换为 Exec 格式，并显式控制参数边界：

1. ✅ 用列表形式调用：RUN ["sh", "-c", "apt-get update && apt-get install -y curl"] —— 注意：sh -c 仍需谨慎，仅用于必要场景
2. ✅ 更安全做法：把逻辑封装进独立脚本，COPY 进镜像后以固定参数调用，例如 RUN ["./scripts/install-deps.sh"]
3. ❌ 禁止字符串拼接：RUN echo "$VERSION" | xargs apt-get install -y package-$1 —— $VERSION 若来自 --build-arg 且未校验，极易被注入

严格校验构建参数与环境变量

通过 --build-arg 传入的值默认不参与层缓存，但会直接进入 RUN 执行上下文。若必须使用，需在 RUN 中做白名单过滤或类型强制：

1. 对数值类参数：RUN [ -n "$MY_PORT" ] && [ "$MY_PORT" -eq "$MY_PORT" ] 2>/dev/null && [ "$MY_PORT" -ge 1024 ] && [ "$MY_PORT" -le 65535 ] || exit 1
2. 对字符串类参数：RUN case "$APP_ENV" in "prod"|"staging") : ;; *) echo "invalid APP_ENV" >&2; exit 1 ;; esac
3. 避免直接引用：不要写 RUN sed -i "s/PORT=.*$/PORT=$MY_PORT/" config.conf —— 应改用模板工具（如 envsubst）或预生成配置

限制执行上下文与权限边界

RUN 默认以 root 执行，且拥有完整网络和文件系统访问能力。可通过 BuildKit 特性缩小攻击面：

1. 禁用网络：RUN --network=none pip install --no-cache-dir flask —— 强制离线安装，阻断恶意包远程拉取
2. 挂载只读文件系统：RUN --mount=type=bind,source=./scripts,target=/scripts,readonly ./scripts/verify-checksums.sh
3. 传递密钥不落盘：RUN --mount=type=secret,id=api_key ./scripts/deploy.sh —— secret 内容仅内存可见，不存入镜像层
4. 切换非 root 用户执行后续操作：先 RUN groupadd app && useradd -r -u 1001 -g app appuser，再 USER appuser，后续 RUN 若需提权，必须显式调用 sudo（且需提前配置）

剥离可信逻辑与不可信来源

最彻底的防御是让 RUN 永远不接触原始输入。推荐采用“两段式”设计：

1. 第一阶段：用多阶段构建，在 builder 阶段解析参数、校验输入、生成配置或二进制产物
2. 第二阶段：runtime 阶段只 COPY 已验证的产物，RUN 仅做轻量初始化（如 chown、chmod），不涉及任何解释型逻辑
3. 示例：builder 阶段用 Python 脚本解析 JSON 配置并生成 Nginx conf；runtime 阶段仅 RUN cp /tmp/nginx.conf /etc/nginx/conf.d/，不执行任何模板渲染

不复杂但容易忽略：真正的加固不在 RUN 行本身，而在它前面那一步——你是否允许任意输入抵达这一行。