# Security of running jobs > 原文：[https://docs.gitlab.com/runner/security/](https://docs.gitlab.com/runner/security/) * [Usage of Shell executor](#usage-of-shell-executor) * [Usage of Docker executor](#usage-of-docker-executor) * [Usage of private Docker images with `if-not-present` pull policy](#usage-of-private-docker-images-with-if-not-present-pull-policy) * [Systems with Docker installed](#systems-with-docker-installed) * [Usage of SSH executor](#usage-of-ssh-executor) * [Usage of Parallels executor](#usage-of-parallels-executor) * [Cloning a runner](#cloning-a-runner) # Security of running jobs[](#security-of-running-jobs "Permalink") 使用 GitLab Runner 时，您应该在运行作业时意识到潜在的安全隐患. ## Usage of Shell executor[](#usage-of-shell-executor "Permalink") **通常，使用`shell`执行程序运行测试是不安全的.** 这些作业在用户权限（GitLab Runner 的权限）下运行，并且可以从此服务器上运行的其他项目中窃取代码. 仅将其用于运行受信任的构建. ## Usage of Docker executor[](#usage-of-docker-executor "Permalink") **在非特权模式下运行时，可以认为 Docker 是安全的.** 为了使这种设置更加安全，建议在 sudo 禁用或`SETUID`和`SETGID`功能已禁用的 Docker 容器中以用户（非 root 用户）身份运行作业. 另一方面，存在特权模式，该模式允许对主机系统的完全访问权限，安装和卸载卷的权限以及运行嵌套容器. 不建议在特权模式下运行容器. 可以通过`cap_add` / `cap_drop`设置在非特权模式下配置更精细的权限. ## Usage of private Docker images with `if-not-present` pull policy[](#usage-of-private-docker-images-with-if-not-present-pull-policy "Permalink") 使用[高级配置中](../configuration/advanced-configuration.html#using-a-private-container-registry)描述的私有 Docker 映像支持时[：使用私有容器注册表时](../configuration/advanced-configuration.html#using-a-private-container-registry) ，应`always`将其`pull_policy`值. 尤其是你应该使用`always`拉的政策，如果你正在主持一个公共，共享亚军与泊坞窗或 Kubernetes 执行人. 让我们来看一个将拉策略设置为`if-not-present`的示例： 1. 用户 A 在`registry.example.com/image/name`具有私有映像. 2. 用户 A 在共享运行器上启动构建：该构建接收注册表凭据，并在注册表中授权后提取映像. 3. 图像存储在共享的 Runner 主机上. 4. 用户 B 无法访问`registry.example.com/image/name`上的私有映像. 5. 用户 B 在与用户 A 相同的共享 Runner 上启动使用此映像的构建：Runner 找到该映像的本地版本并使用它， **即使由于缺少凭据也无法提取该映像** . 因此，如果托管的 Runner 可以由不同的用户和不同的项目使用（具有私有和公共访问权限的混合级别），则永远不要使用`if-not-present`作为拉策略值，而应使用： * `never` -如果您想限制用户使用您预先下载的唯一图像. * `always` -如果您想让用户可以从任何注册表下载任何图像. `if-not-present`拉策略**仅**应用于受信任的构建和用户使用的特定运行器. 阅读[拉取策略文档](../executors/docker.html#how-pull-policies-work)以获取更多信息. ## Systems with Docker installed[](#systems-with-docker-installed "Permalink") > **注意：**这适用于低于 0.5.0 的安装或已升级到较新版本的安装. 在安装了 Docker 的 Linux 系统上安装软件包时， `gitlab-runner`将创建一个有权访问`Docker`守护程序的用户. 这使使用`shell` executor 运行的作业能够以完全权限访问`docker` ，并可能允许对服务器的根访问. ## Usage of SSH executor[](#usage-of-ssh-executor "Permalink") 由于缺少`StrictHostKeyChecking`选项， **SSH 执行程序容易受到 MITM 攻击（中间人）** . 这将在将来的版本之一中修复. ## Usage of Parallels executor[](#usage-of-parallels-executor "Permalink") **Parallels executor 是最安全的选择，**因为它使用完整的系统虚拟化，并且配置为在隔离虚拟化中运行的 VM 机器和配置为以隔离模式运行的 VM 机器. 它阻止访问所有外围设备和共享文件夹. ## Cloning a runner[](#cloning-a-runner "Permalink") 跑步者使用令牌来标识 GitLab 服务器. 如果克隆一个运行程序，则克隆的运行程序可能正在为该令牌选择相同的作业. 这是"窃取"跑步者工作的一种可能的攻击手段.