结论：不适合把 macOS 自动登录当成 GitLab Runner 的默认安全设置；只有在终端策略允许、执行账号权限受控、构建任务可信且重启演练通过时，才应考虑启用。 自动登录解决的是用户会话恢复，不等于 Runner 已在线、构建已成功或主机隔离已达标。
企业 IT 负责人：判断构建节点重启后的恢复方式是否符合终端安全策略。
平台工程师：核实 Runner 的服务模式、执行账号与构建任务边界。
安全负责人：审查自动登录、FileVault、Keychain 和不可信代码作业的组合风险。
00会话状态与 Runner 可用性
GitLab Runner macOS 的运行依赖用户会话。GitLab 官方说明，macOS 上的 Runner 以用户级 LaunchAgent 运行：当前用户登录后启动，退出登录后停止；它不是开机即运行的系统级 LaunchDaemon，官方不支持用后者替代。要在重启后恢复可用，官方文档提到自动登录，但这并不构成企业安全批准。(docs.gitlab.com)
为什么 macOS Runner 会涉及自动登录？
因为 LaunchAgent 随用户登录启动，GitLab 的 macOS 安装说明将自动登录列为重启后保持 Runner 可用的一种方式。检查时应把状态拆开：用户是否登录、LaunchAgent 是否加载、Runner 是否向 GitLab 报到、代表性构建是否成功。只看到 Runner 显示在线，不能证明签名、模拟器或构建流程能正常工作。
可以先核对官方记录的两个配置位置：Runner 配置文件 ~/.gitlab-runner/config.toml，以及 ~/Library/LaunchAgents/gitlab-runner.plist。检查 plist 的触发条件、执行账号、工作目录和日志路径，并记录用户退出后服务是否停止；这比只查看控制台状态更容易定位重启后的断点。(docs.gitlab.com)
01执行账号权限
Runner 以已登录用户身份运行，而且能够访问该用户的 Keychain 和图形会话。对企业来说，这既是 iOS 模拟器、代码签名等工作的条件，也是权限审计的边界：作业可能接触该账号可读写的工作目录、缓存、开发工具、凭证及其网络可达资源。(docs.gitlab.com)
| 核对对象 | 验收证据 | 需要调整的信号 |
|---|---|---|
| Runner 执行账号 | 作业日志中的实际身份；账号所属组与可访问目录清单 | 使用日常员工账号，或任务不需要却具备管理员权限 |
| 文件与工具 | 项目目录、缓存、Xcode 和脚本工具的读写范围 | 不同项目能读到彼此的构建产物或本地配置 |
| 网络访问 | 作业实际可访问的内部服务、制品库与外网目标 | 普通测试任务可接触生产系统或不必要的敏感服务 |
| 管理权限 | 账号权限清单与安装、升级、签名操作的授权记录 | 构建脚本可直接更改系统设置、安装任意软件或管理其他账号 |
建议将构建身份与日常管理身份分开，并通过最小权限限制文件和网络访问；如果构建需求确实需要较高权限，应把例外写入审批记录，同时说明由谁维护、如何撤销。不要把“不是 root”误当成“没有风险”：用户级账号仍可能持有发布证书、项目秘密和其他敏感文件。
02作业隔离与可信来源
Shell executor 在安装 Runner 的主机上本地执行脚本，作业之间的隔离有限。GitLab 提醒，作业使用 Runner 用户的权限，可能访问同一服务器上的其他项目内容；应仅用于来自可信用户、运行在可信主机上的构建。这个判断针对 Shell executor，不应直接泛化到所有 executor。(docs.gitlab.com)
GitLab Shell executor 能否隔离不同项目？
不能只凭项目目录不同就认定已隔离。目录与缓存的分开存放，不等于阻止同一执行账号访问其他项目文件、凭证或本机资源。若同一主机承载多个项目，重点要核对 Runner 分配范围、谁能触发作业、代码是否可信，以及不同任务能否访问同一用户会话和 Keychain。
| 任务来源与信任度 | 建议的承载判断 | 放行条件 |
|---|---|---|
| 内部受控分支、维护者可信 | 可评估共用节点 | 限定可分配项目，确认账号权限、缓存和凭证范围 |
| 外部贡献或来源未经审查 | 不应与发布签名任务共用同一信任边界 | 先限制任务权限与凭证可见性；无法隔离时拆分节点 |
| 多个项目权限不同 | 按项目与凭证敏感程度评估是否拆分 | 通过实际作业验证读写范围，不能只依赖标签或目录命名 |
对不可信代码，架构建议是拒绝其接触含有发布凭证的长期运行节点；如果组织无法提供可靠隔离，就应调整 Runner 分配和主机承载边界，而不是指望清理工作目录解决权限问题。GitLab 的 macOS 设置指南以 Shell executor 配置 macOS Runner，具体采用时仍需结合其安全文档审查任务来源。(docs.gitlab.com)
03FileVault 与登录策略
Apple 支持文档说明，FileVault 开启时，自动登录设置可能不可用；组织管理策略也可能禁止自动登录。因此，不能把“Runner 需要登录”推导成“应该关闭磁盘保护”。磁盘解锁、用户登录与 Runner 在线是不同状态，企业必须按自身加密要求确定恢复设计。(support.apple.com)
开启 FileVault 后，Runner 能否在重启后自动恢复？
不能仅凭 FileVault 开关回答。先确认重启后磁盘是否已解锁，再验证用户会话是否建立、LaunchAgent 是否启动以及 Runner 是否正常接单；其中任何一步未完成，都可能导致节点不能按预期恢复。
Apple 的平台安全文档还说明：在 Apple 芯片 Mac 且运行 macOS 26 或更高版本时，如果已开启“远程登录”并且网络可用，可以在重启后通过 SSH 解锁 FileVault。这是磁盘解锁能力，不代表用户会话已登录，更不证明 Runner 已启动或构建通过。(support.apple.com)
⚠️ 如果企业策略要求 FileVault，不能为了自动登录擅自关闭加密。应先让终端安全团队确认允许的启动与解锁路径，再在隔离节点验证完整恢复链路。
04Keychain 与签名凭证
iOS 签名证书和 Keychain 应放在哪里？
它们应只对确实执行签名发布、且来源可信的作业可用。GitLab 说明，macOS Runner 的用户会话能够访问该用户的 Keychain；安装文档也提示，codesign 可能需要相应会话配置才能读取签名证书。由此可见，把签名凭证放进普通测试任务可访问的执行账号，会扩大受影响范围。(docs.gitlab.com)
验收时逐项盘点证书、私钥、临时签名材料和发布令牌：确认哪些项目能访问，任务结束后凭证是否仍可读取，使用行为是否留有审计记录。建议将签名任务与普通测试任务分开授权，并把凭证轮换、撤销责任和异常处置负责人写入流程。若无法证明凭证只对获准任务开放，不应以“构建暂时成功”作为上线依据。
05重启恢复与上线放行
先在隔离测试节点演练，不要直接用生产签名凭证验证恢复。记录测试前的登录策略、FileVault 状态、Runner 配置和任务来源；重启后依次确认磁盘解锁、目标用户会话、LaunchAgent、Runner 注册状态，再运行能够代表实际工具链的构建任务。GitLab 的服务模式、Shell executor 边界和 Apple 的登录限制，应分别作为核对依据，而不是合并成单一“在线”指标。(docs.gitlab.com)
按下面的验收清单收集证据；每一项都应能对应到配置、日志、权限清单或测试记录。
- [ ] 保存 plist 与 Runner 配置，确认执行账号、启动方式、退出行为和日志位置。
- [ ] 记录该账号对管理员操作、项目目录、缓存、开发工具、网络和 Keychain 的访问范围。
- [ ] 标明 Runner 承载的项目、任务来源及不可信代码的处理方式；无法隔离时，拆分承载。
- [ ] 由终端安全负责人确认 FileVault 与自动登录策略相容；不得为维持在线状态绕过加密要求。
- [ ] 在隔离节点完成重启演练，分别记录磁盘解锁、用户登录、Runner 在线和代表性构建结果。
- [ ] 预先明确自动恢复失败时的人工处置人、恢复步骤与放行或回滚条件。
只有在策略允许、作业信任边界清晰、凭证范围可控且恢复演练通过时，才考虑按该方式放行。若任一关键条件不满足，应先改用经安全团队认可的恢复方式、限制任务范围或拆分节点；不要为保持 Runner 在线而降低组织的保护要求。
如果采用自购 Mac，团队需自行承担硬件采购、现场维护和重启恢复安排；如果用共享节点承载不同信任级别的任务，则要面对凭证暴露与隔离不足的风险。对需要临时增加 macOS CI 承载、且不想先行购置硬件的团队，可以把远程 Mac 纳入候选，但应在采购前核实实际访问方式、登录恢复条件和签名任务交付边界。NUKCLOUD 页面列有 SSH、VNC 和电源管理入口，但这些信息不能替代对自动登录、FileVault 与 Runner 会话行为的验收；可先查看远程 Mac 的访问与功能说明，再根据自身核验结果评估远程 Mac 部署选项。