GitHub Actions 自託管 Mac Runner 安全嗎？2026 隔離清單

共享 Mac 同時保存原始碼、Apple 簽名私鑰、部署令牌及內部網路權限時，真正的風險不是「Runner 是否在線」，而是任務程式能否控制宿主機。GitHub 官方將自託管 Runner 的安全責任交給使用者，並特別警示公開倉庫中的不受信任程式碼可能取得 Runner 環境與後續存取能力。自託管 Runner 說明可作為第一個核對依據。

我們先按來源分級，不要用倉庫名稱代替信任判斷：

GitHub Actions 自託管 Runner 可以服務公開倉庫嗎？
可以把公開倉庫任務放到專用的低權限、無敏感資料節點，但不應讓它接觸簽名身份、部署密鑰或內部管理網路。若節點不能在任務後重建，結論應是禁止承載不受信任程式碼，而不是依賴工作流作者的自我約束。

注意：環境批准只限制某些部署步驟的執行流程，不能把已經控制宿主 Mac 的不受信任程式碼變回安全程式碼。先隔離宿主機，再談發布批准。

Runner Group 是第一道邊界，但它不是完整的安全模型。需要同時核對 Runner 註冊在倉庫、組織還是企業層級，以及預設群組是否意外對其他倉庫開放。GitHub Runner Group 文件說明了群組可見範圍與倉庫存取政策；工作流的 runs-on 則決定工作是否被送到符合條件的 Runner。工作流 Runner 路由文件可用來對照實際設定。

多人共用 Mac Runner，怎樣避免倉庫互相讀取？
不要把「每次刪除工作目錄」當成隔離。先讓不同信任等級使用不同 Runner Group、不同登入帳戶或不同節點，再用倉庫白名單限制路由。若多人任務必須共用同一台長期運行的 Mac，至少要證明工作區、使用者層級設定、進程與憑據不會跨任務留下可讀痕跡；做不到就回退到獨立節點。

GitHub Actions 的 GITHUB_TOKEN、部署密鑰、Apple 簽名身份與生產發布權限，不應長期放在同一個帳戶環境。Apple 對代碼簽名憑證與私鑰的說明，可從Apple 代碼簽名憑證技術文件核對憑證、私鑰及 Keychain 的關係。

Xcode CI 的簽名憑證應該放在哪一類 Runner？
簽名身份應只出現在獨立發布 Runner，或至少是不能被一般建置任務路由到的節點。普通建置 Runner 可以編譯與測試，但不應保存生產私鑰。若產品流程無法拆分，應先降低發布權限、縮小 Keychain 可用範圍，再由人工批准觸發簽名步驟。

要逐項核實：

• GITHUB_TOKEN 是否只授予工作流真正需要的讀取或寫入權限。
• 哪些工作流可以修改，哪些人可以觸發，哪些環境批准者可以放行。
• Keychain 使用哪個 macOS 帳戶執行，是否可被其他任務解鎖或匯出。
• 建置、簽名、公證與發布是否分成不同工作，並使用不同 Runner。
• 憑據是否在工作完成後撤銷、輪換或從節點移除。

環境保護規則可以增加批准門檻，但不能修復宿主機控制權已經外洩的問題。若一個不受信任任務能執行任意程式碼，便應假設它可能嘗試讀取可見的令牌、檔案或 Keychain 狀態。

Mac Runner 每次任務結束後需要清理哪些項目？
至少要檢查倉庫副本、臨時檔案、DerivedData、建置產物、日誌、背景進程、使用者層級設定、SSH 金鑰、環境檔案與 Keychain 痕跡。只刪除工作目錄不能證明節點已恢復乾淨，因為進程、快取、系統設定或其他路徑仍可能保留任務資料。

建議把清理拆成可觀察步驟：

1. 停止並盤點由工作流啟動的背景進程。
2. 移除工作區、臨時目錄、DerivedData 與建置輸出。
3. 搜尋環境檔、日誌與快取中的令牌、憑證及倉庫內容。
4. 檢查使用者的 SSH、Git、Shell 設定及 LaunchAgent 變更。
5. 核對 Keychain 是否新增、解鎖或匯入不應存在的項目。
6. 重啟節點後再次檢查常駐進程、網路連線與檔案權限。
7. 對無法解釋的變更停止派單，轉人工復核或直接重建。

長期運行的 self-hosted runner，怎樣判斷已被污染？
出現未知常駐進程、任務結束後仍有外連、工作區以外出現倉庫資料、使用者設定被改動、Keychain 項目異常，或重啟後狀態仍無法重現時，應視為疑似污染。不要用 Runner 顯示 Online 作為健康證明；在無法重建的共享 Mac 上，先停止敏感任務，再保留磁碟與日誌供人工調查。

列出 Runner 可以連線的內部服務、套件來源、簽名接口、原始碼平台、管理網路與外部目的地。接著問：日常 Xcode 建置是否真的需要 root、完整磁碟存取或不受限制的外網？

建立「應允許」與「應拒絕」兩組驗收目標：

• 應允許：必要的原始碼服務、套件來源、測試服務及指定簽名接口。
• 應拒絕：生產資料庫、管理平面、其他團隊的 Runner、未使用的內網段及不必要的憑據服務。
• 高權限步驟：獨立工作、獨立帳戶或獨立 Runner，並設置人工批准。
• 外連檢查：用受控任務驗證允許目的地，再用拒絕目標確認連線確實失敗。

GitHub 對受損 Runner 的說明提醒，Runner 若被控制，影響範圍取決於它能接觸的權限與資源。受損 Runner 安全文件可用於檢視「節點被控制後，攻擊者還能走到哪裡」，而不是只檢查 GitHub 工作流是否成功。

完成前述檢查後，不要只輸出「安全」或「不安全」。我們建議按以下條件分支作決策：

• 若來源限定為受控私有倉庫，Runner Group 有倉庫白名單，任務只能使用低權限帳戶，且清理與重建測試均通過，則可先上線非生產建置與 Simulator 測試。
• 若節點不能自動重建，但能證明沒有簽名資產、沒有管理網路權限，且每次任務後可人工檢查，則只選低權限共享建置，否則回退到一次性重建節點。
• 若工作流需要 Apple 簽名身份或生產發布權限，則改用獨立發布 Runner，否則不得把私鑰放進一般建置節點。
• 若公開倉庫或外部 Pull Request 可觸發任意程式碼，則禁止派到含有令牌、Keychain 或內網權限的 Runner。
• 若允許與拒絕任務的路由結果無法留下記錄，則先修正審計能力，不進入生產。
• 若發現未知進程、異常檔案或憑據痕跡，則立即停止派單、輪換相關憑據並重建節點。

正式准入前，至少安排四類受控測試：

1. 低權限建置測試：確認一般 Xcode 建置不需要 root，也不會看見簽名資產。
2. 受控簽名測試：只使用測試憑證，確認簽名 Runner 與一般 Runner 的路由不同。
3. 惡意殘留模擬：在測試任務中建立背景進程、臨時檔及使用者設定變更，驗證清理是否能發現。
4. 重啟與復原測試：重啟後重新檢查工作區、進程、Keychain、網路連線及 Runner 註冊狀態。

同時保存以下證據：

• Runner Group 設定與倉庫白名單。
• 允許任務成功、拒絕任務未派送的記錄。
• 工作流權限、環境批准者與觸發者清單。
• 清理前後的檔案、進程、Keychain 與網路檢查結果。
• 憑據輪換、節點重建、備用 Mac 接管的操作記錄。

GitHub 的部署與環境文件可用來核對批准規則及環境保護設定，但批准記錄仍不能代替宿主機清理證據。部署與環境控制說明

若目前方案是把一台辦公室 Mac 或長期共用 Mac 同時當作建置、簽名與內網跳板，缺點通常很具體：任務殘留難以證明已清除、不同倉庫容易共享使用者環境、故障後恢復依賴人工處理，而且節點常被授予超出建置需求的網路權限。這類方案短期方便，長期卻難以留下可審計的隔離證據。

完成信任與權限檢查後，可以先用 MESHLAUNCH 的遠端真實 Mac 做非生產倉庫試驗，重點驗證獨立帳戶、重啟恢復與節點重置能力；相關節點選擇可參考遠端 Mac 方案及Mac mini 遠端部署選項。只有當路由、清理、憑據分層及復原證據都保留下來，才值得把簽名或發布任務遷入該環境。若團隊需要的是臨時測試或可替換的 CI 節點，這種按需使用的真實 Mac 通常比維護一台無法重建的共享主機更容易控制；長期固定重負載或需要實體周邊的情況，則仍應評估自購與專用硬體。