要約

  • GitHub Actions は別のワークフローが要求または完了されたときに workflow_run を起動でき、GitHub は下流のワークフローが上流にはなかったシークレットや書込みトークンを持てると説明している。
  • この接続は成果物の信頼性判定ではない。結論条件、ブランチ・フィルタ、チェックアウト、成果物の選択と取扱い、実効権限はそれぞれ別の判断である。
  • 検証可能な主張には、上流の実行とリビジョン、下流トリガーの設定と評価済み条件、正確な成果物とチェックアウト、権限の文脈、下流の判断、時点を限定した対象観測を結び付ける必要がある。

「検証の後に公開ワークフローが動いた」という言い方は、あり得る構成を表すが、完全な保管連鎖ではない。GitHub Actions では、あるワークフローが要求された、または完了した際に、別のワークフローがその workflow_run イベントを受け取れる。GitHub は、起動された下流ワークフローが、先行ワークフローには与えられていなかったシークレットや書込みトークンにアクセスできる場合があるともしている。権限の低い入力処理が候補を作り、より制約された次の処理が扱いを決める構成は合理的である。しかし、その設計は同時に権限の境界をつくる。上流実行の名前だけでは、その境界を何が越えたかは分からない。

最初に、完了と受入れを分けなければならない。GitHub の説明では、下流ワークフローが明示的な条件、たとえば github.event.workflow_run.conclusion == 'success' を置かない限り、workflow_run は先行ワークフローの結論にかかわらず実行される。従って、上流の実行が終わったという事実は、検査が成功したことも、下流ジョブが意図した結論条件を評価したことも示さない。イベントに現れるワークフロー名は、それを待ち受けるファイルのリビジョンでも、下流が受信したイベントの内容でも、権限の強い手順を通した式でもない。

ブランチ・フィルタにも同じ限界がある。GitHub は、workflow_run のブランチ・フィルタがトリガー元ワークフローのブランチに適用され、包含と除外のパターンには順序があると記す。宣言された branches は方針の意図を示すことがある。しかし、それは成果物が期待したコミットから来たこと、下流のチェックアウトが同じリビジョンに解決したこと、あるいは「リリース・ブランチは通った」という表現が実際に評価された ref を指すことを証明しない。後でこの判断を検証するなら、上流の実行 ID、イベント操作、ヘッド・ブランチと SHA、ワークフローの同一性、再実行の文脈を一緒に残す必要がある。

次が成果物である。GitHub のイベント文書は、下流ワークフローがトリガー元の実行に関連する成果物を取得できる例を示す。これはアクセス経路であって、品質証明書ではない。成果物が上流実行に正しく結び付いていても、後続操作にとって論理的に正しい入力とは限らない。下流は別名の成果物を選ぶかもしれず、単一オブジェクトでなく集合をダウンロードするかもしれず、別の環境で展開するかもしれず、異なるチェックアウトを使うかもしれず、上流の検証が評価していないコマンドに渡すかもしれない。必要な記録は「成果物が利用可能」だけではない。上流実行、名称または識別子、利用できるハッシュとサイズ、取得時刻、下流チェックアウトの ref と解決済み SHA、それを消費したプログラム、隔離または非実行の取扱い条件を含むべきである。

GitHub の安全な利用に関する文書は、この精度が必要な理由を示す。特権ワークフローが信頼できない pull request の内容をチェックアウトする場合、workflow_run は危険になり得ると警告し、シークレット、書込み権限、共有キャッシュが下流の受入れを増幅し得ると注意する。この警告は特定のリポジトリや成果物を非難するものではない。構造を示すものだ。「上流は通過した」では、特権下流が何を受け入れたか、何をする権限を持ったかは見えない。

トリガーは対象への効果の受領証でもない。正しく選ばれた成果物でも、検査だけに使われることがある。下流のコマンドは別の権限境界で拒否されることがあり、対象を呼ぶ前に停止することがあり、別のリソースに作用することがあり、終了しても後の対象観測が別の運用状態を示すことがある。逆に、上流の失敗結論はイベントに残っていても、下流条件が特権操作を止める場合がある。イベント、条件、成果物の取扱い、コマンドの判断、観測された状態は別々の地点である。

実務上の答えは、範囲を限定した下流の受領証である。上流のワークフロー名と実行 ID、イベント操作、ヘッド・ブランチと SHA、結論、試行または再実行、定義への安定した参照を残す。下流定義のリビジョン、workflow_run セレクタ、ブランチ・フィルタ、重要なジョブを許可または阻止した条件結果を残す。チェックアウト指定と解決済み SHA を残す。実際に使った各成果物について、上流との関連、名称または識別子、取得できるダイジェスト、取得文脈、処理経路を残す。GITHUB_TOKEN の実効権限、シークレットの可用性、関係するキャッシュや環境の境界も、秘密値を出さずに残す。最後に、下流操作の結果を、別の時点で行った対象観測に結び付ける。秘密は保護できるが、記録されなかった結合関係を後で作り直すことはできない。

この記録は、パイプライン全体が「信頼できる」とは主張しない。イベントが何を結び、下流が何を決め、何を消費し、どの権限を持ち、何が観測されたかだけを述べる。workflow_run は有用な制御境界になり得る。しかし、記録していない成果物、特権判断、運用上の効果を暗黙に保証する証明書にしてはならない。

出典

  1. GitHub Docs — Events that trigger workflows
  2. GitHub Docs — Secure use reference
  3. GitHub Docs — Triggering a workflow