2026 GitHub Actions 的 Mac Runner 如何隔離外部 PR？

這篇文章寫給需要在自我管理 macOS Runner 執行 CI 的開源維護者、iOS 安全負責人與平台工程師。文章以工作流程來源、Runner 存取、憑據、任務後清理和節點恢復為檢查軸，並提供可直接採用的通過／不通過條件。

GitHub 官方提醒，自我管理 Runner 可能因執行工作流程而遭持續入侵，也不保證每次工作都在乾淨、隔離的執行個體上完成。自我管理 Runner 安全說明 因此，不要讓來源未受信任的外部 PR，直接使用存有敏感憑據或可能留有狀態的長期 Mac Runner；應分流不可信測試與受信任的簽名、發布工作，並驗證存取限制和任務後清理。

適合：需要在自我管理 macOS Runner 執行 CI，並要確認外部 PR 能否進入的團隊。

不適合：只想靠加上 Runner 標籤，就判定外部程式碼已被隔離的團隊。

開源維護者：判斷外部貢獻能否使用自我管理 Runner。 iOS 團隊安全負責人：分開測試建置與簽名發布。 平台工程師：管理 Runner 組、倉庫存取、節點清理與稽核。

GitHub Actions Mac Runner 外部 PR 隔離，第一步要看什麼？

要先查的不是 YAML 裡有沒有 runs-on: [self-hosted, macOS]，而是：實際執行的工作流程來自誰，並且能在節點上做什麼？

工作流程觸發方式會影響可用的權限與機密。一般 pull_request 事件與 pull_request_target 的安全特性不同；後者在基礎倉庫的脈絡中執行，若又檢出並執行 PR 提交的程式碼，可能把較高權限帶給不可信程式碼。請依照 GitHub 工作流程觸發事件說明 和 pull_request_target 安全指引核對實際設定，不要只根據事件名稱推斷安全。

外部 PR 可以在 GitHub Actions 自我管理 Mac Runner 上執行嗎？ 技術上可以設定，但是否應該執行，取決於 Runner 是否為不可信任工作隔離、是否能接觸其他工作留下的資料，以及工作流程可取得的權限。若是長期重用、同時持有簽名憑據的節點，預設應阻擋外部 PR；除非已把不可信工作安排在可清除、權限受限的隔離環境，並實際驗證清理結果。

我們會先把工作流程按信任來源分開記錄：

• 受信任分支：由有權限的維護者管理，可執行建置或發布工作，但發布權限仍應獨立控管。
• 組織內 PR：不能只看 PR 來自內部帳號；還要確認提交者是否有權修改工作流程，以及該倉庫的權限設定。
• 外部貢獻者 PR：視為不可信任程式碼。不要讓它接觸含有機密或其他工作資料的共用節點。

GitHub 對自我管理 Runner 的安全提醒，正是不能把「CI 任務已結束」等同於「主機已恢復乾淨」。工作流程可能執行任意腳本，也可能留下檔案或背景程序；長期共用同一節點時，後續工作便要承受這種殘留風險。GitHub 自我管理 Runner 安全用法

Runner 組的標籤不是權限邊界

標籤是用來讓工作流程選擇符合條件的 Runner，不是倉庫授權機制。工作流程指定預期標籤，只能說明它提出了路由需求，不能證明只有指定倉庫或可信任工作流程能使用該節點。

怎樣限制哪些倉庫可以使用自我管理 Runner？ 檢查 Runner 組允許哪些倉庫使用，並核對組織或企業層級的存取政策；不要只檢查 Runner 上有哪些標籤。GitHub 的 Runner 組存取管理文件說明了如何設定可使用 Runner 組的倉庫。Runner 組本身則提供集中管理及套用存取範圍的方式，詳情可參考官方 Runner 組說明。

實際驗收時，逐一列出能把工作路由至 Mac Runner 的倉庫，並在設定頁確認允許清單與預期相符。若發現來源不明的倉庫可用，或無法說明某個倉庫為何有權存取，應判為不通過。接著再檢查工作流程可否透過條件、重用工作流程或其他設定，避開原本預期的分流方式。

評分：倉庫清單明確、Runner 組存取範圍與設計一致，而且能說明每個允許項目的用途，才可評為「通過」。只靠標籤、文件沒有記錄，或倉庫範圍過寬，都應列為「待修正」；無法限制不可信任工作使用節點，則是「阻擋」。

憑據不可因為沒出現在日誌，就視為安全

PR 測試任務應只取得完成測試所需的最低權限。簽名、發布及其他敏感憑據，應與外部 PR 的測試流程分開。GitHub 說明了工作流程如何使用機密，以及可用機密受事件與設定影響；請依官方機密使用文件核對工作流程與儲存庫設定。

Mac Runner 上的簽名憑據如何與 PR 測試隔離？ 不要把是否安全寄託在「機密沒有列印到日誌」。測試程式仍可能透過其他執行行為接觸它有權使用的環境或檔案；所以要分開測試與發布工作，並檢查測試任務是否能讀取簽名材料、發布權杖、設定檔或其他敏感資料。涉及簽名的任務，只能在明確授權的受信任流程執行。

我們通常按以下原則驗收：

• PR 測試工作流程不應取得簽名或發布所需的機密。
• 發布工作流程不應因為在同一倉庫，就自動信任所有 PR 觸發的工作。
• GITHUB_TOKEN 權限應與該項工作相符；不需要寫入權限的測試，不應配置不必要的寫入能力。
• 若工作流程使用 pull_request_target，不得未經風險檢查便檢出、執行 PR 提交的程式碼。

若無法證明外部 PR 流程碰不到發布憑據，就把它判為不通過，先移除憑據或改走隔離環境，再恢復執行。

任務完成後，清理驗收不能只看 YAML

長期節點可能保留工作目錄、快取、暫存資料或背景程序。清理腳本寫在設定裡，不代表每次都成功執行，更不代表所有執行路徑都會觸發它。GitHub 提供 Runner 工作前後執行指令的設定方式，可參考官方前置與後置腳本文件；但這類設定仍需要實際測試，不能當作隔離保證。

自我管理 Runner 執行完外部程式碼後要檢查什麼？ 用一次不含敏感資料的測試工作流程驗收，而不是只讀設定檔。讓流程建立可辨識的測試檔案、暫存檔及背景程序；工作結束後確認它們是否仍存在，並檢查工作目錄、快取和可重用資料的清理策略。再核對節點是否回到預期狀態，並留存執行紀錄，供負責人複核。

第一步：列出節點會保留的狀態。 包含工作區、建置輸出、快取、暫存檔案、登入狀態與背景程序；無法說明用途的資料，也要列入清理範圍。

第二步：確認清理觸發條件。 檢查正常完成、失敗、中斷及取消時會走哪些清理路徑。若某種結束方式不會觸發清理，該情況就是未處理的風險。

第三步：執行非敏感驗收工作。 讓流程建立測試用殘留物，觀察任務後清理是否生效。不要使用真實簽名憑據作為測試材料。

第四步：檢查節點與記錄。 確認殘留物是否清除，並保留工作結果、清理狀態與複核責任人。只有 YAML 看起來正確，不足以判定通過。

第五步：定義失敗後的復原動作。 若檔案或程序未清除，暫停該節點承接其他工作；依團隊程序檢查並恢復節點，再記錄原因和處理結果。一次測試成功只能證明該次驗收通過，不代表之後每次執行都會安全。

用明確條件決定放行、分流或阻擋

以下條件可直接用於發布前審查。凡是權限範圍不明、清理尚未驗證或無法限制倉庫存取，均不應以「暫時先跑」替代修正。

• 若來源可信、倉庫存取經核准、測試工作無法接觸發布憑據，而且任務後清理已用非敏感工作流程驗證，才可考慮讓該工作使用指定的自我管理 Runner。
• 若外部 PR 需要測試，但節點仍有共用狀態或無法證明清理有效，就把不可信工作分流至隔離環境，不要讓它與受信任發布工作共用節點。
• 若 Runner 組允許的倉庫超出預期，或憑據可能被 PR 測試使用，先阻擋該路徑，縮小存取範圍並分離憑據。
• 若清理失敗或節點狀態不明，停止派送新工作，檢查和恢復節點，記錄處理結果，再由指定負責人複核後決定是否重新啟用。

若目前以長期自我管理節點承接所有工作，主要代價往往是狀態共用、清理驗證與權限管理都要由團隊自行持續維護；遇到清理失敗時，也必須負責停用和恢復節點。若只需要隔離的 Mac 建置環境，可先了解ZekVPS 的 Mac 服務說明，再按實際交付方式和權限邊界驗收；例如也可查看Mac mini 租用選項。租用節點本身不等於自動完成外部 PR 隔離，仍須確認工作流程分流、憑據範圍與任務後清理。若團隊需要長期固定負載或必須掌控實體介面，自行維護節點可能更合適；若是短期測試或需要獨立建置環境，再評估租用方案是否能減少自備硬體與節點維護工作。