GitHubのWebhook送信元IPが追加：固定の許可リストとMeta APIを確認しよう

GitHubは10月29日、github.comからWebhookを配信する送信元IPの範囲を追加した。Webhookは、プッシュなどの出来事をきっかけに、登録したサーバーへHTTPリクエストを送る通知の仕組みだよ。

通知を受ける側で送信元IPを制限している場合、許可リストが古いと正しい通知まで拒否することがある。今回は、固定設定を使う運用か、公式APIから更新する運用かで、確認する点が分かれる。

追加された三つの範囲

公式発表で案内された追加分は、以下のCIDRだよ。CIDRは、IPアドレスの範囲を短く表記する方式。末尾の /28 も範囲を決める情報なので、省略しないでね。

9.234.98.160/28
9.234.98.176/28
9.234.106.48/28

対象は、GitHub Enterprise Cloudを含む、github.com上の全プランのWebhook配信。自社運用のGitHub Enterprise Serverにも同じ値をそのまま適用できる、という発表ではないよ。

固定の許可リストには、既存のWebhook用範囲と合わせて追加する。この三つだけを残して既存の範囲を消す対応ではない。Meta APIに基づいて更新している場合、今回の追加自体に別の変更は不要とされている。

現在の一覧はMeta APIのhooksで取得する

Meta APIは、GitHubのサービスで使うIP範囲などを返すAPI。Webhookに対応する項目は hooks だよ。ほかにも web、api、actions などがあるけれど、名前の似た別の項目を使わないようにしよう。

Python 3が使える端末なら、次の例で現在の一覧を読み取れる。本番の設定を変更する処理ではなく、公開情報を取得して表示するだけだよ。

import json
import urllib.request

with urllib.request.urlopen("https://api.github.com/meta", timeout=20) as response:
    meta = json.load(response)

for prefix in meta["hooks"]:
    print(prefix)

編集部では10月30日に公開APIを取得し、発表された三つが hooks に含まれることを確認した。受信サーバーの設定変更や実際のWebhook配信テストを行った結果とは分けて読んでね。APIの一覧は今後も変わり得るため、記事や公式資料のサンプル値だけを固定して使わず、その時点のAPIを確認しよう。

取得に失敗したときは、通信経路、HTTPの応答、タイムアウトを確認する。自動反映する仕組みなら、取得失敗を空の一覧と扱って既存設定を消す設計にしないことが大切だよ。

どこで拒否されているかを分けて確認する

編集部としては、通知の受信が止まったとき、次の順で確認することを勧める。

1. 通知を受けるサーバーや、その手前のファイアウォール・WAFで、送信元IPによる拒否がないか確認する。WAFはWeb向けの通信を検査する仕組みだよ。
2. 許可リストを更新する仕組みが実際に動いているか、最後の成功日時と参照項目を確認する。
3. 管理するWebhookの配信履歴で、失敗した時刻と受信側のログを照合する。到達前の拒否と、アプリが返すエラーを混ぜない。
4. 影響する範囲をレビューして反映し、管理するテスト用イベントなどで受信を確認する。再配信する場合は、同じイベントで処理が重複しないことも確かめる。

すべてのエラーが今回のIP追加によるものとは限らない。受信URLの変更、TLS、署名検証、アプリ内部の処理も切り分けよう。設定する製品によって操作場所や反映手順は異なるので、管理者向けの正式な手順に沿って進めてね。

IPの許可と署名の検証は両方見る

IPを許可しただけで、通知内容の真正性まで確かめたことにはならない。GitHubの署名検証手順に沿って、Webhookのシークレットと受信した署名を使った検証も維持しよう。

シークレットは、通知を作る側と受ける側だけで共有する非公開の値。コメント欄やログ、リポジトリへ書かないようにしてね。通信の許可と、受け取った内容を信頼できるかの確認を、別々に管理するのがポイントだよ。

公開の自動化を見直すなら、GitHub Actionsの依存ロックも合わせて確認してみよう。通知の到達性と、実行するコードの固定は、別の運用上の確認事項なんだ。