谁会遇到问题：在六国节点的 Apple Silicon 远程 Mac 上并行跑构建/签名，却总遇到一台 match 能解密、另一台 CI Job 读不到 Profile，或在轮换 ASC API Key / CI Token后出现「能编译却不能上传」的假健康状态。本文结论：把密钥族按仓库级与机器级分层，用轮换事件发布单串起 match / ASC / SSH / CI Token，并配最小可验证包 + 回滚窗口。结构：六类痛点 → 三张参数表 → 六步 Runbook → 三 KPI → 选型收束；并与《Fastlane 多机构建》《TestFlight 实务》并联阅读。
在 2025–2026 周期，iOS 发布工程里「看得见证书」但「流水线突然全红」，多数不是单一钥匙串问题，而是凭证真相源漂移：match 仓库滚动了一半、ASC API Key 在组织里被回收但本地 lane 仍引用旧 ID、CI 使用个人 Token 却因权限收敛导致 job 静默失败。下面六条是远程多节点场景下最常翻车的方式。
known_hosts 指纹不一致会吞进「偶发 git 失败」。fastlane lanes 列表，而不跑一条编译→归档→上传沙盒闭环，会把问题defer 到业务发版夜。如果你在评估 GitHub/GitLab 的 OIDC 与细粒度令牌，可以把「谁对哪条 workflow 能访问哪组 ASC Secret」画成矩阵：六国节点只是执行平面，身份平面仍应回到组织 IAM；否则换区扩容只会复制同一逻辑错误。与《自建 Runner 与密钥隔离》并联时，请显式标出哪些 Secret 属于轮换窗口的冻结集。
这张表用于写轮换发布单前的自检：哪些可以进 Git/密钥仓，哪些必须落在单一机器的钥匙串与个人授权里。
| 对象 | 更适合「仓库级 / 组织级」真相源 | 更适合「机器级 / 白名单」隔离 | 六国远程节点的提示 |
|---|---|---|---|
| match 加密仓库 | 证书/描述文件的单一解密出口 | 解密口令只落在 CI Secret 与受限交互机 | 新节点必须先跑 match readonly lane，再进并发池 |
| ASC API Key（Issuer ID / Key ID） | 组织内统一 Key 与权限角色配置 | 上传与元数据变更可拆分多 Key 最小权限 | 与《TestFlight》篇的「上传白名单机」绑定审计 |
| SSH 密钥 | 只读 deploy key（仓库侧） | 每台构建机的 host-only 跳板密钥 | 跨区域跳板建议独立密钥对，避免与人工共用 |
| CI Token / PAT / OIDC | 用仓库级 Secrets + 环境矩阵命名前缀 | 交互式 notarize 或本地验证码步骤 | 无人值守 job 只用窄权限的 project token |
提示：与《跨时区接力 CI》一样，建议把「能上生产的签名动作」限制在少量标签 Runner 上；本篇补齐的是「轮换时这些 Runner 的凭证如何同时切」。
下列不是固定周期合同，而是工程上常见的审计节拍区间；真实落地请以你们安全团队与 Apple 账号策略为准。
| 凭证 | 常见触发事件 | 典型审计节拍（区间） | 轮换后第一验证 |
|---|---|---|---|
| match 仓库证书 | 新设备入库、描述文件到期预警、私钥泄露疑云 | 与证书自然过期同屏评审；中间至少一次 Profile 对照 | 全量 Runner 跑一次 match(type: "development", readonly: true) 同类校验 |
| ASC API Key | 成员离职、权限审计、上传失败码突变 | 常见按季度或按重大发版窗复盘 | 最小上传沙盒：变更构建号但非生产用户可见 |
| SSH（Git/跳板） | 跳板机迁移、漏洞通告、指纹漂移报警 | 按基础设施季度滚动；热点期可加密出口后重配 | 受控 clone + git ls-remote 往返延迟记录 |
| CI Token / PAT | 供应链审计、仓库迁移、Runner 注册变化 | 短生命周期 token 可能 30～90 天（依平台） | 读权限 dry-run + 单一 lane 绿 |
| 策略 | 适用场景 | 代价/风险 | 执行要点 |
|---|---|---|---|
| 冻结并发（Freeze） | 高风险 match/ASC 变更 | 短时间吞吐下降 | 轮换窗内禁止 autoscaling 新节点入池，直至校验脚本全绿 |
| 蓝绿池（Pool A/B） | 中长期六国资源池 | 需要双倍预算窗 | 一池先全量更新 Secrets，再切流量标签 |
| 逐区滚动（Canary） | 影响面不确定的小 Key 更新 | 排期复杂 | 先亚太再北美或反向，以主制品链路为准 |
archive、一次连接 ASC 的 API 调用成功、一次将构建号推到内部测试通道（非外测亦可）。# 例：轮换窗口内的“探针”片段（按你们 Fastlane 封装改名）
# fastlane run verify_signing_consistency
# 期望：所有标记为 signing 的 Runner 输出同一组 Profile 指纹摘要
# CI：限制并行，防 half-rollout
# concurrency-group: release-credentials-${{ github.ref }}
# cancel-in-progress: false
ORG_PROD_ASC / ORG_BETA_ASC 这类前缀，避免六国节点 job 误读环境。口径说明：上述区间来自跨团队发布实践，非 Apple 官方固定 SLA；请与内部安全制度对齐后写进 Runbook。
补充：若你们已在用短期峰值日租节点做发版对冲，请把「入池前 Secrets 快照」与「离池前证书缓存擦除」写进同一张 check —— 避免因临时节点提前释放导致 match 解密状态与组织真相源长期分叉。
凭证轮换的本质是变更管理：需要独占环境、可审计日志与一致的磁盘/网络出口。若六国节点只靠临时借用、没有标签化 Runner 与租期上限，团队会把 match 口令散进私人笔记本，或在未知机器上手工导入证书——短期看似省事，长期会放大合规与排障成本。
个人笔记本与非专属共享机通常难以同时满足钥匙串边界、固定出口与并发冻结策略；当组织要在亚太与北美之间分配「签名白名单池」并维持可重复轮换节拍时，使用覆盖多地区、可按月租/季租与存储档位组合的专业 Mac 云主机，通常比手工协调更稳定。MACCOME 提供 Apple Silicon 物理节点与六国可选区位，适合承载「编译池」与「签名/上传白名单池」分层；建议先阅读公开的多地区选型与租赁价格说明，再把轮换 Runbook 落表。
试点建议：选两台分别贴近主 Git 与主协作区的远程机构建机，跑通一次完整轮换窗口与回滚演练，再决定是否把峰值日租并入季度预算，而不是等到发版夜才发现某区节点仍未更新 Profile。
常见问题
match 与 ASC Key 应该同一天换吗？
不一定。关键是依赖图写清：若上传依赖新 Key，而 match 证书尚未分发到所有节点，应优先完成 match 只读校验后再切上传链。需要节点与租期底表时可对照 多地区节点与租期指南。
六国节点上 SSH 指纹变了怎么办？
把指纹变更纳入轮换事件，与跳板/制品机 owner 对齐；自动化链路建议启用可预期指纹或限定跳板镜像版本，避免「人工 yes 过去」混进 CI。帮助文档见 帮助中心。
轮换后只失败在 TestFlight 上传，该先看哪篇？
上传阶段与证书编译阶段诊断路径不同，建议并联打开《TestFlight 与 Beta 分发实务》并对照 ASC 处理队列，而不是仅重复跑 match。