Security of running jobs

原文：https://docs.gitlab.com/runner/security/

使用 GitLab Runner 时，您应该在运行作业时意识到潜在的安全隐患.

Usage of Shell executor

通常，使用shell执行程序运行测试是不安全的. 这些作业在用户权限（GitLab Runner 的权限）下运行，并且可以从此服务器上运行的其他项目中窃取代码. 仅将其用于运行受信任的构建.

在非特权模式下运行时，可以认为 Docker 是安全的. 为了使这种设置更加安全，建议在 sudo 禁用或SETUID和SETGID功能已禁用的 Docker 容器中以用户（非 root 用户）身份运行作业.

另一方面，存在特权模式，该模式允许对主机系统的完全访问权限，安装和卸载卷的权限以及运行嵌套容器. 不建议在特权模式下运行容器.

可以通过cap_add / cap_drop设置在非特权模式下配置更精细的权限.

使用高级配置中描述的私有 Docker 映像支持时：使用私有容器注册表时，应always将其pull_policy值. 尤其是你应该使用always拉的政策，如果你正在主持一个公共，共享亚军与泊坞窗或 Kubernetes 执行人.

让我们来看一个将拉策略设置为if-not-present的示例：

用户 A 在registry.example.com/image/name具有私有映像.
用户 A 在共享运行器上启动构建：该构建接收注册表凭据，并在注册表中授权后提取映像.
图像存储在共享的 Runner 主机上.
用户 B 无法访问registry.example.com/image/name上的私有映像.
用户 B 在与用户 A 相同的共享 Runner 上启动使用此映像的构建：Runner 找到该映像的本地版本并使用它， 即使由于缺少凭据也无法提取该映像 .

因此，如果托管的 Runner 可以由不同的用户和不同的项目使用（具有私有和公共访问权限的混合级别），则永远不要使用if-not-present作为拉策略值，而应使用：

if-not-present拉策略仅应用于受信任的构建和用户使用的特定运行器.

阅读拉取策略文档以获取更多信息.

注意：这适用于低于 0.5.0 的安装或已升级到较新版本的安装.

在安装了 Docker 的 Linux 系统上安装软件包时， gitlab-runner将创建一个有权访问Docker守护程序的用户. 这使使用shell executor 运行的作业能够以完全权限访问docker ，并可能允许对服务器的根访问.

由于缺少StrictHostKeyChecking选项， SSH 执行程序容易受到 MITM 攻击（中间人） . 这将在将来的版本之一中修复.

Parallels executor 是最安全的选择，因为它使用完整的系统虚拟化，并且配置为在隔离虚拟化中运行的 VM 机器和配置为以隔离模式运行的 VM 机器. 它阻止访问所有外围设备和共享文件夹.

跑步者使用令牌来标识 GitLab 服务器. 如果克隆一个运行程序，则克隆的运行程序可能正在为该令牌选择相同的作业. 这是”窃取”跑步者工作的一种可能的攻击手段.