プロンプトとユースケース
あなたのチームは、リポジトリ間で共有される再利用可能なワークフローへと、ビルド、テスト、およびリリースの各ステップを抽出しています。呼び出し元と呼び出し先のワークフロー間における入力、出力、シークレット、GITHUB_TOKEN 権限、およびバージョン参照のコントラクトを設計してください。権限昇格、サプライチェーンのドリフト、およびコンテキストの混同をどのように防ぐかを説明してください。
面接官がテストしていること
- 再利用可能なワークフローが通常のステップとしてではなく、ジョブレベルで呼び出されることを理解しているか。
- 呼び出し元の
GITHUB_TOKEN権限は、呼び出し先のワークフローによってダウングレード（制限）のみ可能であり、昇格はできないことを説明できるか。 secrets、環境変数、およびgithubコンテキストの露出を最小限に抑えているか。- ネストの制限、呼び出し制限、参照の固定（ピン留め）、および組織ポリシーを適切に処理できるか。
回答前に明確にすべき質問
- 再利用はリポジトリ間、組織（Organization）間、または単一リポジトリ内のいずれかであり、どの可視性ポリシーが適用されますか？
- 呼び出し先のワークフローはアーティファクトのビルドのみを行いますか、それともデプロイ、リリース、リポジトリへの書き戻しが可能ですか？
- シークレットは個別に渡されますか、組織スコープで継承されますか、それとも環境ルールによって保護されていますか？
- アップグレードはブランチ、リリースタグ、またはイミュータブルなコミット参照のいずれを追跡すべきですか？
30秒の回答フレームワーク
私は狭いインターフェースを定義します。workflow_call で型指定された入力、個別のシークレット、および必要な出力を宣言し、呼び出し元のジョブで最小限の permissions を設定し、呼び出し先のワークフローでそれをさらに絞り込みます。リリースワークフローとビルドワークフローは分離したままにし、保護された環境によって機密性の高いデプロイを制御します。参照にはレビュー済みのコミットまたは管理されたタグを使用し、組織ポリシーによって許可されるアクションと再利用可能なワークフローを制限します。最後に、監査ログ、再実行時の動作、および権限のデグレ検証テストによってコントラクトを検証します。
ステップバイステップの詳細解説
1. 再利用可能なワークフローの境界
再利用可能なワークフローは workflow_call によってトリガーされ、呼び出し元はジョブ上で uses を使用します。呼び出し側ジョブは with、secrets、permissions、strategy、および needs などのドキュメントに記載されたキーのみに制限されており、任意のコマンドを挿入できる通常のステップではありません。
2. 入力、出力、および型制約
呼び出し先のワークフローで必須の入力、デフォルト値、および型を宣言し、無効な呼び出し元コントラクトがパース時に失敗するようにします。リリースの自動化に必要なアーティファクトのダイジェスト、バージョン、または結果ステータスのみを公開し、トークン、完全なログ、または内部パスを決して返さないようにします。
3. シークレットを個別に渡す
1つのデプロイアクションに必要な認証情報のみを渡す明示的な secrets マップを推奨します。secrets: inherit は呼び出し元が利用可能なすべてのシークレットを渡すため、厳密に境界が設定された同一組織内のケースには適合する場合がありますが、監査および漏洩の対象面が拡大するため、信頼境界を越える場合には避けるべきです。
4. GITHUB_TOKEN 権限のダウングレード
呼び出し元のジョブは、読み取り専用のソースアクセスとアーティファクトの書き込みなど、permissions を明示的に宣言する必要があります。GitHub のドキュメントでは、呼び出し先のワークフローに継承される権限は同一のままか、より制限的になることのみが可能で、より強大な権限になることはありません。そのため、高権限のアクションには呼び出し元での明示的な付与と、記録されたレビューの根拠が必要です。
5. github コンテキストの所有権
呼び出し先のワークフロー内における github コンテキストは、呼び出し元のワークフローに関連付けられています。呼び出し先のリポジトリのブランチ、イベント、または権限が呼び出し元の情報を置き換えると想定してはいけません。ソースリポジトリ、コミット、またはアクターのIDが必要な場合は明示的に渡し、必要に応じてログ内でマスキング（編集）します。
6. 参照とサプライチェーンドリフト
ワークフローはブランチ、タグ、またはコミットを参照できます。ブランチは移動し、タグは付け替えることが可能です。本番環境のパスでは、レビュー済みのイミュータブルなコミット、または許容される参照を制限する組織ポリシーを使用する必要があります。また、GitHub Actions のポリシーによって、アクションに完全な長さのコミット SHA を要求し、許可されたソースを制限することもできます。
7. ネスト、マトリックス、および並行性
ネストされた再利用可能なワークフローは最大10レベルに達することができ、1つのワークフローファイルは最大50個の一意な再利用可能なワークフローを接続できます。マトリックスから再利用可能なワークフローを呼び出すことも可能ですが、リリースの重複や相互キャンセルを回避するために、各組み合わせにはリソース制限、並行性グループ（concurrency group）、およびキャンセルポリシーが必要です。
8. 監査、再実行、およびロールバック
呼び出し元のリポジトリ、コミット、入力ダイジェスト、権限宣言、およびアーティファクトダイジェストを記録します。すべてのジョブを再実行すると参照が再度解決される可能性がありますが、失敗したジョブの再実行では最初の試行時のコミットが使用されることがあるため、監査記録には実際に解決されたバージョンが含まれている必要があります。ロールバックは検証済みの参照に切り替え、保護された環境の認可を取り消します。
トレードオフと境界線
inheritは設定を削減しますが、シークレットの境界を暗黙的なものにします。組織間またはマルチテナントプラットフォームでは、シークレットを明示的にマッピングする必要があります。- コミットのピン留めは再現性を向上させますが、アップグレードには自動更新、レビュー、およびロールバック期間が必要になります。
- デプロイを汎用ワークフローにパッケージ化すると重複は排除されますが、環境保護が見えにくくなる可能性があります。本番デプロイでは承認の境界を可視化したままにしておく必要があります。
- トークン権限は API を認可するものであり、ランナーファイル、ネットワーク、またはサードパーティのアクションを信頼できるものにするわけではありません。信頼できないコードには依然として分離が必要です。
実装計画と検証
workflow_callの入力、出力、および個別シークレットのコントラクトを作成し、未宣言のフィールドを拒否します。- すべての呼び出し元ジョブの権限マトリックスを生成し、呼び出し先のワークフローが
GITHUB_TOKENを昇格できないことを確認します。 - 本番環境の参照をレビュー済みコミットに固定し、組織の許可リストを設定して、SHA ポリシーを確認します。
- ダミーのシークレットと制限付きリポジトリを使用して、プルリクエスト、リポジトリ間、ネスト、および再実行の訓練を実施します。
- GitHub の再利用可能なワークフロー、ワークフロー構文、および Actions 設定のドキュメントに照らして実装をレビューします。
よくある間違いとフォローアップ質問
間違い1：再利用可能なワークフローをアクションステップとして扱う
これは異なるフィールドとコンテキストのセットを使用してジョブレベルで呼び出されます。ステップ構文をそのままコピーすると、パースに失敗するか、誤った権限の前提が作成される可能性があります。
間違い2：デフォルトで secrets.inherit を使用する
継承を使用すると、呼び出し元がアクセスできるすべてのシークレットが呼び出し先のワークフローに付与されます。信頼境界と組織スコープが明確でない限り、シークレットは個別に渡してください。
間違い3：呼び出し先のワークフローでのみ高い権限を設定する
呼び出し先のワークフローが呼び出し元のトークンを昇格させることはできません。高い権限は呼び出し元のジョブで宣言し、レビューと監査を通じて正当化する必要があります。
フォローアップ：なぜタグ参照には依然としてリスクがあるのか？
タグは移動する可能性があるため、再実行時や後日の実行時に異なるコミットが解決される可能性があります。本番環境では、レビュー済みのコミットを固定するか、組織ポリシーで許可される参照を制限する必要があります。
フォローアップ：シークレットが漏洩していないことをどのように証明するか？
ダミーのシークレットと最小権限を使用してパス全体を実行し、ログ、出力、アーティファクト、およびエラーパスを検査し、inherit、環境変数、およびサードパーティアクションの読み取りアクセスを監査します。