公司动态 · 发布时间：
短期租用计算设备部署 Runner，容易忽略一个关键问题：流水线任务执行的代码未必可信。短期租用计算设备搭建持续集成Runner的安全隔离，应先明确任务边界，再决定设备形态、凭据范围和回收方式。无论使用 GitLab Runner 还是 GitHub Actions 的自托管 Runner，都不要把“任务结束”当成“风险消失”。
先判断租用设备要隔离什么
CI 任务会读取仓库、安装依赖、运行测试并生成制品。若合并请求来自外部贡献者，构建脚本和依赖也可能执行不可信操作。因此要分别限制四类访问：其他任务的数据、宿主机资源、外部网络，以及部署密钥等凭据。
先列出任务实际需要的资源。例如，单元测试通常只需代码仓库和依赖源；发布任务才可能需要制品仓库或部署权限。不要为了方便，在所有流水线中放入同一组长期有效的密钥。
虚拟机和容器，隔离强度不同
优先考虑一次性虚拟机
如果任务运行不可信代码，或需要使用 Docker 构建，优先选择每个任务独立的虚拟机，完成后销毁。虚拟机边界通常比共享内核的容器更清晰，但仍需限制管理面、网络和云平台权限；销毁虚拟机也不能自动撤销已经外传的凭据。
容器适合边界明确的轻量任务
容器启动和回收较快，适合可信仓库中的常规测试。应避免让构建容器直接挂载宿主机 Docker 套接字，也不要默认启用特权模式；这类配置会显著扩大任务对宿主机的控制能力。若容器长期复用，还要防止工作目录、缓存和残留进程跨任务泄漏。
按顺序配置，避免凭据跟着设备一起“常驻”
- 验收租用设备。确认登录方式、操作系统镜像来源、管理账号交接和到期回收流程；更换初始密码，关闭不需要的远程入口。
- 创建专用执行身份。Runner 使用独立账号运行，不授予日常管理员权限。管理账号只用于维护，不作为流水线任务身份。
- 划分任务队列。将可信分支的发布任务与外部合并请求的验证任务分开。外部代码不应获得部署密钥、写入令牌或可访问生产环境的网络通道。
- 缩小凭据范围。优先使用短时、单用途凭据，并按仓库或环境授权。秘密变量只提供给确实需要它的受保护任务；日志中避免打印秘密值。
- 限制网络与数据留存。按任务需要开放依赖源和制品服务，能限制出站访问时就不要给任意外网访问。检查缓存、工作目录和构建制品是否包含令牌或私有配置。
- 完成后回收。停止 Runner，撤销其注册令牌和临时凭据，清除磁盘上的工作目录与缓存，再按租用约定销毁设备或恢复干净镜像。确认操作记录可追溯。
常见失误：隔离了进程，却没隔离权限
把任务放进容器，不代表它不能接触挂载目录、主机套接字或环境变量。使用 Docker-in-Docker 时，也应评估特权容器和共享存储带来的风险。更稳妥的做法是把构建任务与发布任务拆开：前者只产出经过校验的制品，后者在受保护的执行环境中取得有限权限，再从可信制品来源发布。
短期租用计算设备搭建持续集成Runner的安全隔离，核心是让每次任务只拿到完成工作所需的最小权限，并确保任务结束后环境和凭据都能回收。设备租期短，不等于凭据泄露窗口短；真正的边界来自任务分区、权限控制和可验证的销毁流程。
常见问题
短期任务需要长期注册 Runner 吗？
不一定。若平台和部署方式支持临时 Runner，可按任务或短批次注册并在结束后注销；否则要设置明确的停用、令牌撤销和设备销毁步骤。
能否让外部合并请求使用自托管 Runner？
只有在执行环境不含敏感凭据、与其他任务隔离且网络权限受控时才考虑。否则，应改用隔离程度更高的临时执行环境，或不让外部代码运行在该 Runner 上。
怎样确认清理已经完成？
核对 Runner 已离线或注销、令牌已撤销、临时密钥已失效，并检查工作目录、缓存及制品中是否残留秘密；仅删除流水线记录不足以证明设备数据已清除。
