GitHub 对临时自托管 Runner 的说明是:每个 Runner 最多执行 1 个 job 后自动注销;但重新使用硬件,仍需自动化准备干净环境。GitHub 自托管 Runner 文档
症状:签名任务结束了,私钥却可能还在可复用 Mac 的钥匙串或工作目录中。
最快解法:把长期保管、工作流授权和运行时签名分开管理;只向可信发布任务注入最小权限凭据,无法验证任务隔离与清理时,先隔离 Runner,不要只依赖加密存储。
企业 IT 或安全负责人:核查 iOS 发布凭据的保管、授权与撤销流程。
平台工程师、iOS 技术负责人:评估 GitHub Actions macOS Runner 的凭据注入方式,以及现有共享节点是否适合生产签名。
GitHub Actions macOS Runner iOS 签名密钥管理:三个位置各司其职
“密钥放哪”不能只回答一个存储产品名称。应分别记录以下三处,避免把加密存储误当成构建任务隔离:
- 长期保管位置:保存签名凭据的来源,可以是 GitHub Actions Secrets,也可以是按组织政策选用的外部凭据库。评估重点是访问范围、授权方式、轮换责任和可审计记录。
- 工作流授权入口:决定哪些仓库、环境和任务能取用凭据。GitHub Secrets 可设在仓库、环境或组织层级;组织级 Secrets 还能按仓库访问策略限制范围。GitHub Secrets 参考
- 任务运行时:签名动作需要在 macOS 上使用代码签名身份。Apple 说明,证书本身只有公钥;用于签名的身份还需要与其对应的私钥。Apple 代码签名证书说明
因此,.p12 或私钥即使来自受控凭据库,一旦被导入 Runner,任务运行期间仍要保护实际运行环境。Apple 的资料也说明,导入导出的代码签名身份会进入钥匙串;“放在钥匙串”描述的是使用位置,不代表该钥匙串天然是短期或任务专属的。Apple 签名身份同步说明
长期保管:GitHub Secrets 与外部凭据库的取舍
GitHub Actions Secrets 的优点是能直接进入工作流授权链路;仓库、组织和环境级别的作用范围各不相同。代价是团队需要持续审核哪些仓库和工作流能引用凭据,并承担轮换与撤销流程。GitHub 文档还指出,单个 Secret 上限为 48 KB;超出时应重新设计凭据交付,不要把它拆散后直接写进脚本或日志。Secrets 限制与读取规则
外部凭据库 是否更合适,取决于该服务实际支持的身份验证、授权、审计与轮换能力,以及团队是否已配置并验证这些控制。不能仅凭“外部”或“加密”推断其能力。GitHub 在安全文档中建议,使用支持的云服务或凭据管理方案时,可评估通过 OIDC 获取短时、范围受限的访问令牌;但这不等于 OIDC 自动替代 Apple 签名私钥,私钥如何交付和如何退出运行时仍需单独设计。GitHub 安全使用说明
按以下维度比较更可靠:
- 访问控制:GitHub Secrets 要核对组织、仓库、环境的授权范围;外部凭据库则要核验它自身的身份与策略配置。
- 轮换责任:明确由谁生成、更新、撤销证书和私钥,以及工作流如何切换到新凭据。
- 审计能力:确认实际能查到哪些访问或变更记录,保留期限与管理员范围是什么;没有文档或实测证据时,不把“可审计”当作既成事实。
- 使用范围:仓库级 Secrets 会让该仓库工作流处于相应授权范围;组织级 Secrets 可通过访问策略限制仓库,但仍不隔离同一台 Mac 上运行的任务。
工作流权限:把发布凭据限定在可信任务
GitHub Actions 的环境可以限制哪些任务使用环境 Secrets,并配置审批规则;审批通过后,相关 job 才能取得环境 Secrets。环境最多可设置 6 名必需审查者,但这只是平台提供的审批配置,不是对 Runner 执行环境的隔离保证。GitHub 部署环境文档
尤其要区分“谁获准拿到 Secret”和“谁能影响拿到 Secret 的 Runner”。GitHub 明确提示,自托管 Runner 不保证每次运行都处于干净、临时的虚拟机中;不可信工作流可能影响 Runner 环境。环境审批或 Secrets 授权不能消除这个边界。
- 只让受信任的发布分支和发布工作流触及生产凭据;对拉取请求、外部贡献和混合信任任务,不授予签名凭据。
- 给发布 job 单独设置
permissions,只开放所需的GITHUB_TOKEN权限;GitHub 工作流语法支持按权限项指定read、write或none。工作流权限配置 - 审核第三方 Action 的来源、版本和输入方式。避免把敏感值作为命令行参数传递,因为其他进程或审计记录可能暴露命令行内容;优先使用该工具支持的环境变量或标准输入方式。
- 用 Runner group 限定可访问 Runner 的仓库和工作流。它能帮助管理路由与使用范围,但不是同一台主机上不同任务之间的操作系统级隔离。
运行时隔离:临时钥匙串并不等于临时主机
临时钥匙串是把签名身份限制在构建执行环节的一种设计选项。Apple 的 Security 框架提供创建临时钥匙串的能力;但是否成功限制可访问主体、是否在任务结束后真正移除,以及同机其他任务是否能读取,仍要由团队在实际 macOS 环境中验证。Apple 临时钥匙串接口说明
macOS 临时钥匙串能解决什么? 它可以把导入操作与长期钥匙串区分开来;它本身不能证明构建账户隔离可靠,也不能证明文件副本、进程参数、临时目录或日志里没有敏感内容。不同仓库能否读取同一台 Mac 上的签名凭据? 不能仅凭仓库使用了不同 Secrets 或不同环境,就得出“不能”的结论;需要检查操作系统账户、任务并发、钥匙串解锁状态、工作目录权限和 Runner 复用方式。
⚠️ GitHub 自动脱敏不是清理证明。官方说明指出,秘密值经过转换后不保证总能被自动识别和脱敏;因此不能把“日志里没看到明文”当作私钥未泄漏的证据。
| 待确认环节 | 验收时应查看的证据 |
|---|---|
| 任务边界 | Runner 分组、可访问仓库、并发策略及运行账户配置。 |
| 凭据导入 | 任务触发条件、导入步骤、临时文件位置与文件权限;禁止在记录中保存真实密钥或令牌。 |
| 签名调用 | 构建日志中的命令与输出经过脱敏检查,确认没有意外打印敏感环境变量。 |
| 任务结束 | 钥匙串删除或退出、临时目录处置和失败分支的清理记录;不能只看清理脚本返回成功。 |
| 访问审计 | 把 GitHub 侧审批与工作流记录、主机侧账户及文件访问证据分开留存,并注明各自能证明什么。 |
清理验收:让“脚本成功”变成可复核记录
导入与清理至少按下面的顺序试点。每一步都记录预期结果、实际证据和失败时的处置;证据中不要出现真实签名密钥、令牌或敏感日志。
- 盘点入口:列出所有能触发生产签名任务的事件、分支、仓库、复用工作流和第三方 Action。对无法确认来源或审查流程的入口,先移出生产签名路径。
- 收窄授权:为发布任务选择最小可用的 Secrets 范围;启用适用的环境审批,并记录审查者、分支规则与凭据管理员。GitHub 文档说明,写入仓库的用户可能有权限使用该仓库配置的 Secrets,因此还要检查仓库写权限人员范围。
- 建立专用运行时:在隔离构建任务中注入凭据,创建或指定临时钥匙串,再执行签名。把构建账户、钥匙串访问控制和工作目录权限都纳入测试,而不是只检查导入命令。
- 验证成功与失败路径:分别测试签名成功、构建中断、导入失败和清理失败时的行为。检查任务结束后钥匙串和临时文件是否按团队定义的预期消失;未验证的场景应明确标为未知。
- 留存验收证据并演练撤销:保存脱敏后的工作流记录、审批记录、Runner 与账户配置快照、清理结果和负责人;再核验凭据撤销、替换后,旧凭据不再被生产任务调用。平台日志能说明平台记录到的事件,不能单独证明主机上不存在残留。
如果团队采用每任务临时 Runner,也要区分 Runner 注册生命周期和宿主机清理生命周期。GitHub 的 Runner 文档建议以自动化为临时 Runner 准备干净环境,并提醒复用硬件仍可能留下前序环境信息;因此“任务后注销”不能直接当成“主机已净化”的证据。GitHub Runner 生命周期与自动化说明
选型评分与条件分支
以下“高/中/低”是依据团队信任边界做的初筛,不是 Apple 或 GitHub 的安全等级,也不是对任何服务的认证结论:
- GitHub Secrets + 可复用共享 Runner:凭据授权集中度中;任务间隔离低,除非已通过真实环境测试证明不同工作流无法读取或影响彼此的签名材料。自托管 Runner 并不保证每次都运行在干净环境中。
- 受控凭据来源 + 隔离构建任务 + 临时钥匙串:职责分离度高;实际隔离强度取决于主机、账户、并发和清理验收。不能把“临时”二字当作验证结果。
- 混合信任任务共用 Runner,且无法提供残留检查证据:生产签名适配度低;先拆分 Runner 组或运行环境,再讨论将生产凭据接入。
按条件收口:
- 若团队只有一个受信任发布团队,且发布入口、账户边界、临时钥匙串与失败清理均有证据,则可试点最小权限凭据注入和隔离任务;否则先缩小可访问范围。
- 若多个团队、多个仓库或混合信任任务共用 Mac,优先分隔 Runner 与签名凭据权限;仅增加环境审批,不足以替代执行环境隔离。
- 若无法验证清理、并发和账户边界,不要把生产签名任务放入当前共享节点;先改造环境或改用可证明隔离边界的执行方式。
- 若外部凭据库不能清楚说明授权、审计和撤销机制,不要因其“外部存储”标签就默认优于 GitHub Secrets;先完成能力核验和小范围试点。
试点前,建议先整理签名任务清单、Runner 共享范围、凭据授权者和清理证据,再确认团队所需的 macOS 环境是否可独立验收。自购 Mac 适合需要长期稳定占用、物理接口或团队自行掌控维护的场景,但要承担采购、维护和更新责任;沿用共享节点可减少新增设备,却可能留下权限交叉、任务残留和责任边界模糊的问题。若需求是阶段性试点或临时扩充 Mac 构建环境,可评估 ArmMacs 的套餐信息 与 可用环境位置说明,并把凭据导入、账户权限、任务隔离和清理验收逐项核实后再决定是否承载生产签名任务。
ArmMacs Cloud Mac
为发布流水线准备一台独享 Mac
通过 ArmMacs 租用独享物理 Mac mini,按需接入自托管 Runner,系统与任务环境由你的团队管理。
