GitHub公式は、自己ホスト Runner が管理対象の一時環境と同じ「毎回クリーンな隔離」を保証しないと説明しています。自動化実行環境の安全利用に関する公式ガイダンスにもとづけば、GitHub Actions 自己ホスト Mac Runner の安全性は、Online 表示ではなく、信頼元、権限、資産、残留、ネットワーク、復旧で判定します。
時間表：今週の推奨アクション
本日は公開リポジトリと署名ジョブを共有 Mac から外し、今週中に Runner Group、実行アカウント、Keychain、作業領域、許可先、再構築手順の証拠を集めます。再構築できないノードは低権限ビルド専用に戻し、署名と公開は別の Mac へ移します。
このチェックリストの対象
Xcode ビルドや Simulator テストを GitHub Actions で実行するモバイル開発チーム向けです。Runner Group、リポジトリ権限、ネットワーク境界、ノード運用を担当する DevOps・プラットフォーム担当者にも適しています。
Apple の署名証明書、macOS Keychain、製品公開の承認を管理する担当者は、特に「ビルド成功」と「署名資産を守れること」を別々に確認してください。
まず信頼元を比較する：公開コードか、管理済みコードか
公開リポジトリ、不明な Pull Request、外部コントリビューターがワークフローを変更できるリポジトリは、署名用 Runner に接続しません。ワークフローの変更権限とジョブの実行権限が同じ経路にある場合、ソースコードだけでなく、実行アカウントから見えるファイルや環境変数も攻撃対象になります。
私たちは次の順で判定します。
- 公開リポジトリ、または不受信のコードを実行する場合：自己ホスト Mac Runner への接続を禁止します。
- 管理者が変更を承認し、Runner Group とネットワークを分けられる場合：低権限ノードで隔離試行します。
- 受信者、変更者、承認者を列挙でき、署名ノードを別にできる場合：本番候補にします。
確認対象は、誰がワークフローを変更できるか、誰が実行を開始できるか、誰が環境承認を行うかです。GitHub も、侵害された Runner がジョブ終了後まで影響を残す可能性を説明しています。侵害された Runner に関する公式説明を根拠として、ノードの再利用を前提にしない設計にします。
第一段階：Runner Group とルーティングを実測する
Runner はリポジトリ、組織、企業のどの階層に登録されているでしょうか。既定グループが意図せず複数リポジトリへ開放されていないか、許可リストとラベルが一致しているかを確認します。
ラベルはルーティング条件として便利ですが、ラベルだけで信頼境界を作りません。ワークフローの runs-on、トリガー条件、Runner Group の許可先を同時に確認します。Runner Group のアクセス制御とジョブの実行先を選ぶ仕様を照合してください。
合格証拠
- 許可されたリポジトリのジョブだけが対象ノードで実行される。
- 許可されていないリポジトリのジョブは拒否または別ノードへ送られる。
- Runner Group、リポジトリ名、ラベル、ジョブ結果を記録している。
- JIT 登録を使う場合も、ホスト自体が清浄になったとは扱わない。
第二段階：トークンと署名資産を分ける
GITHUB_TOKEN の権限、リポジトリのデプロイ鍵、Apple の署名証明書、公開権限を同じユーザー環境に置かないでください。読み取り専用ビルドと公開処理では、必要な資格情報の種類が異なります。
Apple のコード署名証明書は秘密鍵との組み合わせで機能します。Apple の証明書とコード署名に関する技術文書を確認し、どの実行アカウントが Keychain 項目を利用できるかを記録します。
| 用途 | 推奨する Runner | 許可する資産 | 停止条件 |
|---|---|---|---|
| 通常のビルド | 共有可の低権限ノード | 読み取り用トークン、依存キャッシュ | 他チームの鍵や証明書が見える |
| Simulator テスト | テスト専用ノード | テスト用設定、必要最小限のログイン情報 | 常駐プロセスを消せない |
| 署名・公開 | 分離した専用ノード | 対象アプリの署名資産のみ | 再構築手順や承認記録がない |
環境承認は公開操作のゲートにはなりますが、ジョブ実行中にホストが制御された場合の被害を消しません。署名処理の前に、実行アカウント、Keychain のアクセス範囲、証明書の配置、公開先を個別に検証します。
注意：署名ジョブを承認制にしても、同じ Mac で不受信コードのビルドを先に実行したなら、ホストの信頼状態は回復しません。承認とホスト隔離は別の管理対象です。
第三段階：ジョブ後の残留を「削除」だけで終わらせない
作業ディレクトリを消すだけでは不十分です。リポジトリのコピー、DerivedData、アーカイブ、ログ、一時ファイル、ユーザー設定、LaunchAgent、バックグラウンドプロセス、Keychain の一時項目を確認します。
次のチェックを自動化できない場合、長期稼働ノードへの機密ジョブを止めます。
- [ ] ジョブ終了後に作業コピーと DerivedData が残っていない。
- [ ] 未許可のプロセスと常駐エージェントがない。
- [ ] SSH 鍵、トークン、証明書の一時ファイルがない。
- [ ] シェル設定、PATH、依存ツールに想定外の変更がない。
- [ ] 再起動後も同じ検査に合格する。
- [ ] 異常時に資格情報を失効させ、ノードを再構築できる。
GitHub の自己ホスト Runner は、利用者側がホストの更新、アクセス制限、クリーンアップを担います。自己ホスト Runner の責任範囲を確認し、Online 状態を復旧証拠にしないでください。
第四段階：ネットワークと管理者権限を狭める
Runner が到達できる内部 Git サーバー、パッケージリポジトリ、署名サービス、管理ネットワークを一覧にします。ホストが制御された場合、そこから到達できる範囲が実際の被害範囲です。
日常の Xcode ビルドに root、完全ディスクアクセス、無制限の外向き通信が必要かを分解します。必要な高権限処理は独立ジョブにし、専用アカウントと承認境界を設けます。
合格証拠は「許可した接続」と「拒否される接続」の両方です。たとえば依存パッケージ取得は許可し、管理用ネットワークや別チームの秘密管理サービスは拒否されることを実行ログで示します。
最終判定：条件分岐で本番投入を決める
- 信頼できるリポジトリ、限定された Runner Group、低権限アカウント、残留検査、通信制限、再構築手順がそろう場合は、通常ビルド用として採用します。
- 署名資産を別 Keychain と別実行アカウントに分け、公開権限と承認者を限定できる場合は、独立したリリース Runner を追加します。
- 作業後の清掃はできるが、ホスト全体を再構築できない場合は、署名と公開を停止し、低権限ビルドだけに戻します。
- 許可先、残留、アカウント境界、復旧結果を証明できない場合は、自己ホスト Mac Runner を本番から外し、使い捨てに近い実行環境または管理型の実行環境へ切り替えます。
本番投入前には、低権限ビルド、管理された署名、意図的な残留の検出、再起動後の再検査を行います。GitHub の環境承認にも、ジョブの実行前に承認を要求する仕組みはありますが、承認そのものがホスト隔離を保証するわけではありません。環境保護ルールの公式仕様と実機の検査結果を別々に保存します。
よくある判断の分かれ目
公開リポジトリで GitHub Actions の self-hosted runner を使う構成は、ソースの公開性だけでなく、ワークフロー変更者とホスト上の資産を見て判断します。共有 Mac に署名秘密鍵と内部ネットワーク権限があるなら、ビルドが成功しても本番投入の条件は満たしません。
複数チームで同じ Mac を使う場合、ワークスペースの削除だけでは相互参照を防げません。実行アカウント、Keychain、プロセス、ログ、ネットワークを分けられないノードは、Xcode CI の署名用ではなく、低権限の検証用として扱うべきです。
自前の物理 Mac を用意する場合は、購入後の初期化、アカウント管理、故障時の交換、常時稼働の運用も必要です。Mac mini の導入条件を確認する案内と、MESHLAUNCH の Mac 利用環境を比較し、短期の検証か長期の専用運用かを先に決めてください。
まとめと次の一手
自托管 Mac Runner は、公開コードを実行する共用ノードではありません。信頼元、Runner Group、トークンと Keychain、残留、ネットワーク、復旧を証拠付きで検査し、署名ノードを分離できる場合だけ本番に近づけます。
自前の共有 Mac は、初期化の手間、故障時の復旧遅延、署名資産と内部ネットワークが同居しやすい点が弱点です。まずは MESHLAUNCH の隔離した Mac を非本番リポジトリで試し、独立アカウント、再起動後の状態、ノード再構築の実測記録をそろえてから、署名や公開処理へ移すのが安全です。短期の検証や一時的な Xcode CI なら、購入前にこの受け入れ試験を行う方が判断を誤りにくくなります。