GitHub Actions macOS RunnerのiOS署名鍵はどこに置く？2026年企業向け選定

症状：共有のmacOS Runnerに署名鍵を置いたまま、複数のビルドで使い回している。
最短の見直し：秘密鍵をRunnerへ長期保存せず、信頼できるリリース処理だけに必要最小限の資格情報を渡し、隔離した実行環境の一時キーチェーンで利用します。共有範囲や終了後の状態を検証できない場合は、本番署名の前にRunnerを分離してください。

企業IT・セキュリティ担当者：iOSリリース資格情報の保管、承認、撤回手順を点検したい方。
プラットフォームエンジニア：GitHub Actions macOS Runnerへの資格情報の注入と、ジョブ終了後の処理を設計する方。
iOS技術責任者：現在の共有ビルド環境を本番署名に使えるか判断する方。

GitHub Actions macOS RunnerのiOS署名鍵管理は、保管と実行を分けて考えます

iOS署名で使う証明書と秘密鍵は、長期保管場所と、ビルドが実際に署名する場所を分けて管理します。署名鍵を暗号化して保管しても、同じRunner上で別の信頼できない処理が動けるなら、実行環境の分離ができたとは限りません。

Appleはコード署名の仕組みで、証明書と秘密鍵が署名アイデンティティに関わることを説明しています。Appleのコード署名証明書に関する技術資料とチームで署名証明書を共有する際の説明を確認し、証明書だけでなく対応する秘密鍵を含む資産として扱います。

まず、各層の責任を切り分けます。

GitHub Secretsはワークフローで資格情報を参照させる仕組みであり、Runnerのジョブ分離や、処理後に鍵が残らないことまで自動的に保証するものではありません。利用可能な設定や制約は、GitHub Actions Secretsの公式リファレンスで対象環境ごとに確認してください。

資格情報の保管先は、制御と監査の要件で選びます

GitHub Actions Secretsと外部の資格情報保管先は、保管と受け渡しを評価する選択肢です。どちらを採用しても、秘密鍵を使えるワークフローやRunnerの境界まで自動で定義されるわけではありません。

外部保管先を選ぶ場合は、製品名や「集中管理」という表現だけで判断せず、当該サービスの公式資料でアクセス制御、監査、連携方法を確認します。現行のGitHub機能についても、Secretsの利用範囲と参照条件を確認し、実際のリポジトリ構成で試してください。

次の比較は、特定サービスの機能保証ではなく、企業側が要件を評価するための目安です。

この比較で重要なのは、保管方式の優劣より「誰が、どの条件で、どのRunnerに鍵を渡せるか」です。GitHubのセキュリティに関する安全な利用方法は、ワークフローやRunnerを含むリスク確認の根拠になります。

Runnerを共有するなら、署名タスクの信頼境界を先に確認します

自社管理のRunnerは、組織が管理する実行環境ですが、そこで動くすべてのワークフローが同じ信頼度とは限りません。GitHubは、自社管理Runnerについて、信頼できないワークフローが実行される場合のリスクを説明しています。自社管理Runnerの公式資料を踏まえ、署名鍵の受け渡しと、Runnerを利用できるタスクの範囲を一緒に評価します。

「専用」と名付けるだけでは、実際の隔離の証拠になりません。どのリポジトリ、ブランチ、ワークフローがそのRunnerを利用できるかを一覧にし、予定外のタスクが同じアカウント、作業領域、キーチェーンに到達できないことを確認します。

ワークフローで扱う権限は必要最小限にし、GitHubのワークフロー権限設定を実際の設定と照合します。リリース承認を利用する場合も、デプロイ環境と承認に関する説明に基づいて承認条件を確認します。承認やSecretsの公開条件は、実行環境そのものの隔離とは別の制御です。

第三者Actionを使うワークフローでは、そのActionのソース、更新方法、参照する権限を審査対象にします。承認済みブランチから起動したという理由だけで、ワークフロー中のすべての処理を信頼済みと見なす設計は避けます。

第一段階：実行時の一時キーチェーンを使い、処理後を検証します

macOSキーチェーンへのインポートは、ビルドが署名を実行するための段階です。長期保管場所の代わりではなく、どのジョブが利用し、処理後にどの状態になるかを管理する必要があります。Appleの一時キーチェーンを作成するAPIの説明は、一時キーチェーンを扱う実装を調べる際の資料になりますが、企業環境での清掃完了や隔離を保証するものではありません。

導入は次の順に進めます。

• 署名資産と利用先を棚卸しします。 対象の証明書、対応する秘密鍵、利用するリポジトリ、リリース担当、更新・撤回の責任者を記録します。秘密情報そのものをチケットやログへ貼り付けない運用も定めます。
• Runnerの信頼範囲を整理します。 同じMacで動くワークフロー、利用できるアカウント、作業領域、キャッシュ、共有ディレクトリを確認します。信頼度の異なるタスクが同じ境界を使うなら、署名資格情報を渡す前に分離を検討します。
• 資格情報の保管元と受け渡し条件を決めます。 GitHub Secretsか外部保管先かを選ぶ際は、アクセス権、監査、更新、撤回の担当を明記します。どちらを選んでも、ワークフローが参照できる条件を別に審査します。
• ジョブ実行時に一時キーチェーンを用意します。 署名処理に必要な情報だけを読み込み、ビルド用アカウントと作業領域へのアクセスを確認します。資格情報をコマンド引数やデバッグ出力へ露出させないよう、実際のログで検証します。
• 署名処理後の終了手順を定義します。 キーチェーンの削除、作業ファイルの扱い、キャッシュの範囲をジョブの成功・失敗の双方で点検します。スクリプトが終了したことだけを、鍵素材が消えた証拠にはしません。
• 試験実行で残存と権限を確かめます。 実行後にキーチェーン、作業領域、ログ、キャッシュを検査し、想定外のアクセスがないことを記録します。確認できない項目が残る場合は、本番署名へ移行しません。

終了後の証拠は、削除コマンドの成否と分けて記録します

受け入れ記録には、インポート元、利用したワークフロー、署名処理の結果、キーチェーンの削除確認、ログのマスキング確認、実行アカウントの権限を含めます。証跡に秘密鍵やトークンを記録してはいけません。

この表の証拠項目は、チームが定める受け入れ管理の例です。GitHubやAppleがこの一覧を一律の要件として定めているという意味ではありません。プラットフォームの明示機能と、組織が追加で確認する制御を分けて記録してください。

条件分岐で本番署名の可否を決めます

• 信頼できるリリースワークフローだけがRunnerを利用し、実行時の一時キーチェーンと終了後の状態を試験で確認できる場合は、限定したパイロットで本番署名を評価します。
• 複数チームや異なる信頼度のタスクが同じRunnerを共有する場合は、Secretsの保管方法を変えるだけで済ませず、Runnerと資格情報の利用権限を先に分離します。
• キーチェーン、作業領域、ログ、キャッシュの確認方法が定まらない場合は、その共有ノードで本番署名を行わず、隔離できる構成を整えてから再評価します。
• 既存のMacで必要な境界を実現できるか判断できない場合は、試験用の署名処理と受け入れ記録を先に作り、実環境で確認できた範囲だけを採用します。

評価表は、秘密情報の保管だけでなく、実行タスクと終了後の検証までを含めて作成します。共有Mac上の権限設計を詳しく確認する際は、共有Macのサポート情報も参照し、必要な隔離条件を整理してください。

よくある質問

FAQ：署名資格情報を扱う前の確認

自社管理のmacOS RunnerにiOS署名用の秘密鍵を保存しても問題ありませんか？

再利用するRunnerへ秘密鍵を恒常的に置く構成は避け、信頼できる署名ジョブにだけ実行時に渡す方法を検討します。自社管理であることは、同じ環境で動くすべてのワークフローが安全であることを意味しません。分離を説明できないなら、先にRunnerの利用範囲を分けます。

署名証明書はGitHub SecretsとmacOSキーチェーンのどちらに置くべきですか？

長期保管と実行時利用は役割が違います。GitHub Secretsや外部の保管先はワークフローへの受け渡し元として評価し、macOSキーチェーンは署名処理中に使う場所として扱います。保管元の選定とRunnerの隔離は、別々の審査項目にしてください。

別々のリポジトリから同じMacの署名鍵を読めないようにするには？

まず、署名資格情報を参照できるワークフローとRunnerの利用者を絞ります。信頼度の異なるリポジトリが同じ実行環境を使い、ジョブ間の境界を検証できない場合は、資格情報の暗号化に頼らずRunnerを分離します。アカウント、作業領域、キーチェーンも試験対象です。

GitHub Actionsのジョブ終了後、読み込んだ署名鍵はどう処理しますか？

一時キーチェーンを含めた終了処理を設計し、成功時と失敗時の双方で実行後の状態を確認します。削除コマンドの成功だけでは、ログ、作業ファイル、キャッシュなどに鍵素材が残らない証明にはなりません。秘密情報を出力せずに検査できる方法を決め、受け入れ記録に残します。

署名鍵を扱う際、GitHub Secretsはワークフローへの認可と受け渡しを助けますが、共有Runner上のタスク間隔離や削除確認の代わりにはなりません。既存ノードの共有範囲、権限一覧、終了後の確認記録を先に揃え、証拠が不足する条件はパイロットで検証してください。

すでにあるMacを継続利用する方法は、物理的な管理や既存運用を保ちやすい一方、調達、保守、利用境界の設計を自社で担います。共有Runnerでは別チームの処理が混在しやすく、短期試験のために専用機を購入すると利用後の遊休や資産管理も課題になります。隔離したmacOS環境を用意する選択肢を比較する場合は、ArmMacsのレンタルプランで利用条件を確認し、署名資格情報の接続方法、アカウント境界、清掃の証拠を満たせるかを個別に確かめてください。レンタルを選ぶ場合も、安全性や適合性は契約前の実環境試験で判断します。

よくある質問