Security of running jobs

• Usage of Shell executor
• Usage of private Docker images with if-not-present pull policy
• Usage of SSH executor

Security of running jobs

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

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

Usage of Docker executor

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

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

使用高级配置中描述的私有 Docker 映像支持时 ，应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 可以由不同的用户和不同的项目使用（具有私有和公共访问权限的混合级别），则永远不要使用作为拉策略值，而应使用：

• always -如果您想让用户可以从任何注册表下载任何图像.

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

Systems with Docker installed

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

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

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

Usage of Parallels executor

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