GitLab Runner 本身不提供卷挂载黑名单机制，无法原生阻断高危路径挂载；真正有效的安全防护需依托 Docker daemon 层控制、宿主机文件系统加固、Runner 白名单配置及 CI 脚本层静态扫描四层纵深防御。
GitLab Runner 本身不提供卷挂载黑名单机制，也没有“刚性阻断高危路径挂载”的原生功能。这是关键前提——Docker 和 Kubernetes 的权限控制模型决定了：Runner 作为上层调度器，无法在容器启动前主动拦截或校验 --volume 参数中是否含 /etc/shadow、/root、/proc 等敏感路径。这类行为发生在 Docker daemon 层，而 Runner 默认信任 executor（如 docker executor）的配置。
真正可行且生产级安全的做法，是在容器运行时基础设施层面做隔离与限制，而非依赖 Runner 配置。以下是实际有效、已被验证的四层防御策略：
1. 禁用 privileged 模式 + 限制 volume 来源为只读或受限路径
在 Runner 的 config.toml 中，强制约束 docker executor 行为：
[[runners]]
name = "secure-node-runner"
url = "https://gitlab.example.com/"
token = "xxx"
executor = "docker"
[runners.docker]
privileged = false
volumes = ["/cache", "/tmp:/tmp:rw", "/var/run/docker.sock:/var/run/docker.sock:ro"]
# ⚠️ 不要写 /:/host:rw 或 /etc:/etc:rw 这类全盘映射
disable_cache = false-
privileged = false是底线，否则容器可逃逸并直接访问宿主机设备； -
volumes列表应显式声明、严格白名单化，禁止使用通配符或根路径挂载； - 若需共享构建缓存，用
/cache这类专用目录，由 Runner 用户（UID 999）拥有，避免跨用户污染。
2. 使用 Docker daemon 的 volume 插件或 seccomp/apparmor 策略拦截危险挂载
在宿主机 Docker 服务侧加固（需 root 权限）：
- 启用
seccomp默认策略（Docker 20.10+ 默认启用），阻止mount()系统调用挂载敏感文件系统； - 配置
apparmorprofile，拒绝容器内进程对/etc/shadow、/etc/passwd的openat、read权限； - 使用
docker-volume-rclone或local-persist等插件替代裸路径挂载，实现逻辑隔离。
3. 在 Runner 所在宿主机设置挂载点保护
通过 Linux 内核挂载选项预防越权访问：
# 将 /etc 标记为 noexec,nosuid,nodev,bind,ro（只读+无执行） sudo mount -o remount,ro,noexec,nosuid,nodev /etc # 对 /etc/shadow 单独加锁（需提前备份） sudo chown root:root /etc/shadow sudo chmod 000 /etc/shadow # 容器内即使挂载也无法读取
注意：此操作影响宿主机自身，仅适用于 Runner 专用节点，且需确保系统服务仍能正常认证（例如改用
authconfig或sssd替代本地 shadow 查找）。
4. CI 脚本层静态扫描 + 动态拒绝
在 .gitlab-ci.yml 中嵌入防护逻辑，作为最后一道网关：
stages:
- pre-check
check-volume-safety:
stage: pre-check
image: alpine:latest
script:
- |
if grep -q 'volume.*[/]\(etc\|root\|proc\|sys\)' .gitlab-ci.yml; then
echo "ERROR: Detected high-risk volume pattern in CI config" >&2
exit 1
fi
- |
if git diff --staged --name-only | grep -E '\.gitlab-ci\.yml$' >/dev/null; then
echo "CI config changed — manual review required before merge"
fi
allow_failure: false配合 Merge Request approval rule（要求 Security Team 审批含 volume 修改的 MR），形成流程闭环。
本质上，这不是“配置 Runner 黑名单”的问题，而是构建纵深防御体系：
Docker daemon 层控权 → 宿主机文件系统加固 → Runner 白名单约束 → CI 流水线静态检查。
任何单点方案都可能被绕过；只有组合落地，才能刚性阻断物理路径越权挂载。
