GitHub Actions macOS Runner 的 iOS 簽名金鑰放哪？2026 企業選型

症狀：不同儲存庫共用一台持久化 macOS Runner，iOS 發布金鑰可能留在建置環境中。
最快解法：不要長期保留簽名私鑰；只讓受信任的發布工作流取得最小權限憑據，在隔離任務中匯入 macOS 臨時鑰匙串，並驗收任務後的清理證據。

本文適合負責簽名憑據保管、授權與撤銷流程的企業 IT 及安全負責人。
平台工程師可據此設計 GitHub Actions macOS Runner 的憑據注入和清理流程。
iOS 技術負責人則可用文中的條件，判斷現有共享建置節點是否適合承載生產簽名工作。

先分清憑據保管、工作流授權與執行時使用

GitHub Actions macOS Runner 的 iOS 簽名金鑰管理，不能只回答「金鑰放在哪裡」。長期憑據保管、工作流是否有權取得憑據，以及建置程序如何在 macOS 上使用簽名身份，是不同控制邊界；任何一層都不能代替其他層。

Apple 說明程式碼簽名身份涉及憑證與對應私鑰。這代表匯入憑證的程序若能使用私鑰完成簽名，該執行環境就應納入風險評估，而不能只把 .p12 檔案視為唯一需要保護的物件。可對照 Apple 對程式碼簽名憑證與私鑰的說明。

GitHub 文件說明 Secrets 可用於工作流，但仍須按其設定方式及存取範圍評估；可參照 GitHub Actions Secrets 文件。外部憑據管理方案則應逐項核對其存取控制、輪換流程與稽核記錄，不應只因「存在外部保管庫」便假設建置節點不會接觸明文憑據。

長期保管方案應按責任與稽核能力比較

GitHub Actions Secrets 與外部憑據庫處理的是保管和授權問題，不是 macOS 執行環境本身的隔離。選型時要把憑據由誰建立、誰負責輪換、哪些工作流可使用，以及出事後能否追查列為不同問題。

GitHub 對工作流安全使用的說明提醒，第三方 Action、工作流程式碼及權限配置都會影響風險評估，參見安全使用 GitHub Actions 的官方指引。若選用外部憑據庫，企業仍需驗證其取用流程與工作流授權，並把供應商文件中未明確承諾的能力視為待查項目，而非既成事實。

實際成本也不應只比較保管服務的費用。至少要納入維護 Runner 與憑據設定的人力、節點更新及故障處理、憑據輪換與撤銷，以及稽核證據保存等項目。若採購比較涉及遠端 Mac，應先依團隊作業方式盤點環境需求，再參閱 ArmMacs 的租用方案；不能在沒有實際價格和用量資料時，直接宣稱租用或購置哪一種一定更便宜。

執行時用臨時鑰匙串，不等於任務已隔離

簽名身份需要在建置執行階段可供簽名程序使用。Apple 提供建立鑰匙串的安全性介面，說明可在程式執行時建立鑰匙串；這是執行控制的參考，不代表單靠建立臨時鑰匙串就能保證私鑰清除。可查閱 Apple 的臨時鑰匙串介面說明。

實作上，團隊應把建置帳戶、鑰匙串檔案、工作目錄與暫存憑據一起檢查。若多個儲存庫或不同信任等級的工作流輪流使用同一個持久化 Runner，僅改用不同工作目錄，不能證明作業系統狀態彼此隔離。GitHub 對自託管 Runner 的說明也要求使用者評估由工作流執行所帶來的環境風險，參見自託管 Runner 文件。

注意：把鑰匙串刪除命令放進工作流程，只能證明工作流程包含這項動作；清理是否完成、取消或失敗時是否執行，以及其他位置是否還有副本，都必須在實際環境驗證。

可採用以下操作步驟建立可稽核的執行流程：

1. 盤點憑據與使用者。 列出簽名憑證、對應私鑰、provisioning profile，以及哪些儲存庫和發布流程需要使用。不要將任何真實金鑰或令牌寫入文件、工單或日誌。
2. 選定長期保管來源。 由責任人決定使用 GitHub Secrets 或經核實的外部憑據管理方案，並記錄誰可設定、誰可授權、誰負責輪換及撤銷。
3. 限制工作流入口。 只向受信任的發布工作流提供所需憑據；核對工作流權限、第三方 Action 來源及環境審批設定。GitHub 的 部署環境文件可用於核對環境與審批設定，但審批不是主機隔離。
4. 隔離建置任務。 將生產簽名工作與不受信任的分支、外部貢獻者工作流及其他團隊任務分開評估。工作流權限可按 GitHub 的工作流語法文件核對；權限收斂仍不能取代 Runner 邊界。
5. 在任務執行時匯入。 建立臨時鑰匙串，將簽名身份匯入供本次簽名使用的環境；避免把憑據寫入版本控制、永久工作目錄或輸出日誌。
6. 設計退出與失敗路徑。 將登出或鎖定、移除臨時鑰匙串、清理憑據檔案與工作目錄列入流程，並檢查工作取消、簽名失敗及 Runner 中斷時的處理。
7. 保存驗收證據。 以無敏感內容的記錄證明工作流使用了預期憑據來源、簽名步驟完成、清理流程被觸發，並由具權限的人員檢查節點是否仍有可用的簽名身份。不得把單一腳本的成功狀態等同於完整清除證明。

若團隊需要進一步確認共享 Mac 的帳戶及存取安排，可先檢視 ArmMacs 的支援與環境說明，再依實際服務內容核實，不應將一般產品說明推定為特定的簽名隔離承諾。

權限與清理驗收決定生產簽名能否上線

受信任分支、發布環境審批與最小權限令牌，都應納入授權檢查；但這些設定回答的是「工作流能否取得或執行某項操作」，不會自動把持久化共享 Runner 轉變成彼此隔離的執行環境。GitHub 對安全使用及自託管 Runner 的文件可作為平台邊界參照，具體控制仍須依企業自己的 Runner 架構實測。

以上屬於團隊的驗收控制，不是 Apple 或 GitHub 對所有企業環境訂定的通用強制要求。簽名身份如何同步與使用，可參照 Apple 的團隊簽名身份說明；但團隊仍須按自身節點、帳戶與憑據注入方式檢查實際效果。

按團隊信任邊界選型

• 若生產簽名只由受信任的發布團隊執行，且 Runner 任務隔離、憑據授權及清理都有可檢查紀錄，可評估受控憑據注入與 macOS 臨時鑰匙串；先用非生產簽名任務驗證整條流程。
• 若多個團隊或不同信任等級的工作流共用節點，優先分隔 Runner 與憑據權限，再評估是否容許該節點接觸生產簽名身份。
• 若不能證明任務結束後的清理及其他工作流無法接觸簽名身份，不要讓生產簽名任務進入該共享 Runner；改用邊界可驗證的專用建置環境。
• 若團隊尚未整理憑據責任人、輪換流程和審計方式，先完成清單與試點紀錄，再選定保管方案；不要只因某種保管方式提供加密，就跳過執行環境的評估。

對照現有方案時，長期自管 Mac 可能涉及硬體折舊、更新維護及故障處理；一般共享節點則可能增加權限協調、任務互相影響與清理驗證的負擔。租用遠端 Mac 可作為另一種建置環境選項，但不會自動解決憑據授權或 Runner 隔離問題；企業仍須按租用環境的實際帳戶、存取方式和驗收證據逐項確認。若團隊缺少可隔離的 macOS 試點環境，可向 ArmMacs 了解遠端 Mac 是否符合試點及驗收需求；若工作負載長期穩定且需要專用實體硬體，購置自有設備也可能更合適。最後應以簽名任務清單、Runner 共享範圍、權限設定和真實清理紀錄作為上線依據。

常見問題