要点

  • deploy key を使う SSH リポジトリ操作の障害を GitHub は Critical とした。
  • 7月21日10:31:44から11:57:01 UTC まで約85分続き、失敗は断続的だった。
  • 最近のコード変更を可能性のある原因としてロールバックしたが、最終原因とは断定していない。
  • deploy key は機械による特定リポジトリ操作に使われ、clone、fetch、push の失敗が一部の配信を止め得る。
  • 全 SSH、HTTPS、ユーザー鍵、全デプロイやデータの障害は報告されず、詳細 RCA は今後公開予定である。

deploy key は、一台の機械に特定リポジトリへの SSH 権限だけを与える。人のアカウント全体を共有しないため、安全上は望ましい。しかし、その一つの鍵がビルドや配信の入口なら、可用性上は重要な単一経路になる。

影響は顧客側の接続図で広がる

ビルドサーバー、ミラー、リリースシステム、機器更新が deploy key で clone、fetch、push する場合、認証に失敗するとコードを取得できない。後段の計算資源や配信先が正常でも処理は始まらない。

ただし、全てのデプロイが失敗したわけではない。HTTPS、ユーザーSSH 鍵、キャッシュ済みコード、別リポジトリを使う経路は継続した可能性がある。GitHub は対象リポジトリ数も公表していない。

確認された範囲は deploy key SSH 認証であり、各組織はそこに接続した製品や環境を自ら特定する必要がある。

断続障害は状態を混在させる

一度目が失敗し二度目が成功すると、実行器ごとに結果が変わる。画面では失敗でも、再試行が外部操作まで進んだ場合がある。

非冪等な処理を再実行する前に、コミット ID、成果物ハッシュ、公開記録、配信先の状態を照合すべきだ。GitHub はコードやリポジトリの消失を報告していないが、顧客側の再試行設計が重複を作る可能性はある。

ログにはリポジトリ、秘密でない鍵 ID、操作、時刻、試行番号を残し、秘密鍵自体は残さない。これでサービス障害とローカルな失効・設定不良を区別できる。

ロールバックは強い手掛かりだが最終回答ではない

GitHub は最近の変更を可能性のある原因と呼び、元に戻した。直後の復旧は関係を強く示すが、どの認証機構が変わったか、なぜ断続的だったか、どの防御が見逃したかまでは説明しない。

詳細 RCA は未公開である。従って、コード変更を確定した根本原因と書くことはできない。

認証経路の棚卸しから始める

SSH deploy key だけに依存するジョブを一覧化する必要がある。HTTPS の代替は可用性を高め得るが、権限拡大や承認回避、管理されない秘密を生んではならない。

再試行は上限と退避を設け、後段を冪等にする。取得するコミットを固定し、復旧後に再検証する。「ソース未取得」と「配信先操作が実行済みかもしれない」を区別することも重要だ。

GitHub 全体が停止した事故ではない。より限定的で実務的な教訓は、最小権限の鍵でも広い自動化の可用性単点になり得ることだ。RCA には変更だけでなく、本番到達を許した制御の説明が求められる。

出典