【判定：条件付きで採用】 GitLab Runner macOSの自動ログインは、デフォルトの安全策として有効にせず、ユーザーセッションへの依存、FileVaultの要件、実行アカウントの権限、作業の信頼境界を確認してから採否を決めます。保護要件を満たせない場合は、Runnerをオンラインに保つためにセキュリティ設定を弱めず、ノードとジョブの境界を見直してください。
企業IT担当者：再起動後のMac CIノードの復旧方法が、端末セキュリティ方針に適合するかを確認したい方。
プラットフォームエンジニア：Runnerの起動方式、実行アカウント、ビルド処理の境界を点検したい方。
セキュリティ担当者：自動ログイン、FileVault、Keychain、不可信コードの組み合わせを審査する方。
00GitLab Runner macOSの自動ログインを安全性から判定する
自動ログインで解決できるのは、再起動後にユーザーセッションが必要となる構成の復旧問題です。CIサービスの起動、Runnerの登録状態、実ジョブの成功、ホスト上の作業分離まで、自動ログインだけで保証されるわけではありません。
GitLabのmacOS Runner設定では、Runnerをユーザー単位のLaunchAgentとして実行する方法が案内されており、ユーザーセッションが運用上の前提になります。設定時には、LaunchAgentの配置場所と起動条件、ログアウト時や再起動時の挙動を実機で確認してください。
- [ ] RunnerがLaunchAgentとして動いているか、サービスの実行主体と設定ファイルの場所を記録する。
- [ ] OS起動、ディスクのロック解除、ユーザーログイン、LaunchAgent起動、Runnerオンラインを別々の状態として確認する。
- [ ] ログアウトや再起動の後、実際のビルドが完了するまでを記録し、Runnerのオンライン表示だけで受入済みにしない。
01実行アカウントとホスト権限の確認
Runnerの実行アカウントがアクセスできる範囲は、ジョブがホスト上でできることを左右します。特に、管理者権限、共有フォルダー、開発ツール、ネットワーク上の資源を、タスクに必要な範囲に絞れているかを棚卸しします。
GitLab RunnerのmacOS設定ガイドに沿ってサービス構成を確認したうえで、設定上のユーザー名だけでなく、代表的なジョブ内で実際の実行ユーザーを照合してください。
- [ ] 実行アカウントが読み書きできるホームディレクトリ、作業領域、共有フォルダーを一覧にする。
- [ ] 管理者権限の有無と、ネットワーク上で到達できる内部資源を確認する。
- [ ] 開発ツールやキャッシュへのアクセスが、ジョブの目的に対して過剰でないかを検証する。
02Shell executorの作業分離を評価する
GitLab Shell executorはジョブをRunnerホスト上で実行する方式です。GitLabのShell executorに関する説明では、他の実行方式と同等の隔離があるとは扱われていません。そのため、異なるプロジェクトの処理や信頼度の違うコードを同じホストで動かす場合、ジョブが触れられるファイルや環境の共有を評価する必要があります。
これはShell executorの特性に基づく構成上のリスク評価であり、すべてのexecutorに同じリスクがあるという意味ではありません。外部からのコントリビューション、社内の信頼済みコード、署名を行うリリース処理を区別し、Runnerの割り当て方とホストの再利用範囲を決めてください。
- [ ] ジョブの信頼元と、Runnerに割り当てるプロジェクトを対応付ける。
- [ ] 外部コードと、社内の署名・公開ジョブを同じ実行アカウントや作業領域に置かない設計を検討する。
- [ ] 作業領域やキャッシュがジョブ間で共有される条件を確認し、必要ならノードまたはRunnerを分ける。
Shell executorを使うだけで、プロジェクト間のセキュリティ境界が成立するわけではありません。信頼できないコードを同じホストで実行する場合は、ジョブ定義の権限だけでなく、ホスト上で読み出せる資源と資格情報を基準に判断します。
03FileVaultとログイン条件を照合する
Appleは、FileVaultが有効な場合に自動ログイン設定が利用できないことがあると案内しています。設定の可否や復旧の成立は環境ごとに確認し、組織が求めるディスク保護を自動ログインのために無効化しないでください。Appleの自動ログイン設定に関する案内とFileVaultによるディスク保護の説明を、端末ポリシーと併せて確認します。
アーキテクチャ上の判断として、ディスクが解除されていない状態、ユーザーがログインしていない状態、Runnerが利用可能でない状態は別の障害点です。どの状態から手動対応が必要になるかを明文化し、対応する担当者と連絡経路も決めてください。
- [ ] FileVaultの適用要件と、自動ログインを許可する組織ポリシーが整合しているか確認する。
- [ ] 暗号化を維持した状態で再起動試験を行い、ディスク解除とユーザーログインの成立を記録する。
- [ ] 自動復旧できない場合の担当者、手順、復旧後の再確認項目を定める。
04Keychainと署名資格情報の露出を抑える
署名用証明書や秘密鍵を読み取れるアカウントで、通常のテストジョブも実行すると、ジョブの信頼境界が曖昧になります。Keychainへのアクセス権をアカウント単位とジョブ単位で確認し、署名を行わない処理から資格情報を使えない構成にしてください。
- [ ] Runner実行アカウントが利用できるKeychainと証明書を特定する。
- [ ] 署名ジョブの実行元、必要な資格情報、許可する操作を記録し、通常のテストジョブと分ける。
- [ ] 資格情報の利用記録を確認できるか、ジョブ終了後に不要な一時ファイルや環境変数が残らないかを検証する。
05再起動後の受入証跡を残す
本番投入の判断では、設定ファイルやRunnerのオンライン状態だけではなく、隔離環境で行った復旧試験の結果を根拠にします。代表的なビルドを実行し、ユーザーセッション、Runnerの登録、作業結果を一連の証跡として残します。
- [ ] 本番と同じセキュリティ方針を適用した隔離ノードで再起動を試す。
- [ ] ログイン状態、LaunchAgentの起動、Runnerの登録・接続状態を個別に記録する。
- [ ] 署名を伴わない代表的なビルドを実行し、成果物とログを確認する。
- [ ] 署名ジョブは別の信頼境界で試し、Keychainアクセスと資格情報の利用記録を確認する。
- [ ] 自動復旧に失敗した場合の手動対応を実施し、担当者と復旧後の再開条件を記録する。
受入の判定は、組織のFileVault要件を保ったまま復旧でき、ジョブの権限と信頼境界が説明できる場合に限ります。証跡が不足する場合は導入を保留し、Runnerの割り当て、実行方式、ホスト分離を調整してから再試験してください。
06よくある確認事項
ユーザーセッションとRunnerの起動
macOS LaunchAgentとして動くRunnerは、ユーザーセッションに依存する構成があります。自動ログインを設定したとしても、ログアウト後の挙動や再起動後の登録状態、ビルド成功を個別に確認する必要があります。復旧試験では各状態の時刻とログを残してください。
FileVaultを維持した再起動復旧
FileVaultを有効にした環境では、自動ログイン設定が利用できない場合があります。自動ログインを可能にする目的で暗号化要件を下げず、ディスク解除、ユーザーセッション、Runner接続を分けて検証してください。手動解除が必要なら、それを前提とした運用責任と復旧時間の許容条件を設定します。
Shell executorで分離できる範囲
Shell executorのジョブはホスト上で実行され、強いプロジェクト間隔離を前提にできません。共有アカウント、作業ディレクトリ、キャッシュ、Keychainへの到達性を調べ、信頼元が異なるジョブは別Runnerまたは別ホストに分けるべきか判断してください。
iOS署名用Keychainの置き場所
署名資格情報は、通常のテスト処理からアクセスできない実行環境とアカウントに限定するのが基本です。署名ジョブの信頼元、Keychainのアクセス制御、利用記録、ジョブ終了後の清掃を受入対象に含めてください。必要条件を満たせない場合は、署名処理を別のRunner境界へ移す判断が必要です。
自社設置のMacは、機器の調達、OSや開発環境の保守、再起動時の現地対応を社内で担う必要があります。一方、共用ホストで信頼度の異なるジョブを動かす構成は、作業分離や署名資格情報の保護を別途設計しなければなりません。臨時の検証環境やMac CIノードを比較検討する際は、NUKCLOUDの案内で提供条件を確認し、サービス情報と照らし合わせてください。契約前には、アクセス方式、ログイン復旧条件、署名作業の扱いを確認し、実際のセキュリティ要件を満たす場合に限って候補に含めるのが適切です。