同じGitHub Actionsのラベルでも、AWSで動くことがあります
YAMLを変えていないのに外部サービスへのログインが失敗する場合、実行基盤も手掛かりになります。GitHubは10月28日、Linuxの実行容量をAzureに加えてAWSへ広げると発表しました。ラベルが同じでも外部から見える送信元は変わり得ます。
同じラベルの裏で実行先が広がります
対象は標準2・4コアLinuxと、特殊構成のない互換2・4コアlarger runnerです。Windowsやプライベートネットワークなどは対象外です。Free・Pro・Teamは対象ランナーに自動適用、Enterprise CloudはActions > Hosted compute cloud providersでAWSを有効化できます。
既存ラベルと構文を維持し、利用可能なプロバイダーにジョブを配分します。狙いは容量不足による待ち時間と耐障害性の改善です。個々の処理の高速化や、同じジョブの二重実行を保証する発表ではありません。
断続的な失敗に見える仕組み
仮にデプロイAPIがAzureのアドレスだけを許可していると、同じ処理でも別の出口からは拒否され得ます。GitHubはMicrosoft Entra Conditional Accessのネットワーク条件にも言及しています。これは説明用の例で、実際に体験した障害ではありません。
トークンを作り直す前に、接続時刻・宛先・送信元IP・適用ポリシーを照合すると段階を分けられます。実行前の容量待ちと、開始後の認証拒否は別の問題です。容量が増えてもアクセス規則そのものは直りません。
IPは文字列より範囲として読みます
公式の入口はGET https://api.github.com/metaのactions配列です。REST文書はサンプルを転記せず現在値を取得するよう案内しています。ローカルで実行したPython ipaddressの例では文書用192.0.2.0/24に.10と.200は含まれ、198.51.100.10は含まれません。実際のランナーIPではありません。
全範囲の許可が常に適切とは限りません。ランナー文書は標準の範囲が多いため内部資源の許可リストへの利用を推奨せず、固定IPのlarger runnerやセルフホストを挙げています。送信元ネットワークだけで主体を認証せず、最小権限も維持する必要があります。
ラベルが同じでも前提は変わります
まず開始前と開始後のどこで失敗したかを分け、現在の範囲と実際の制限を照合します。固定した出口が必要なら、その要件に合うランナーを選ぶのが自然です。ラベルをクラウド事業者の識別子と思い込まないことが今回の要点です。