# 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 服务器. 如果克隆一个运行程序,则克隆的运行程序可能正在为该令牌选择相同的作业. 这是"窃取"跑步者工作的一种可能的攻击手段.