この記事はGoogle Cloud Platform Advent Calendar 2020の2日目の記事です。
1週間経っても空いていたので雑に埋めにきました。
Cloud MonitoringのUptime checksを利用すると、任意のURLやインスタンスの死活監視を設定することができるのは周知の事実だと思います。
ここで、インスタンスレベルの死活監視をしたいときにちょっとした問題があることは一度でも設定を行ったことがある方にはお馴染みですね。
インスタンスの監視を行うということは、当然VPCネットワークに設定したファイアウォールの影響を受けるということです。
つまり、Uptime checksのリクエストが送信されてくるsource IPアドレス範囲がわかっていて、それらを許可しないと正しい状態を知ることができません。
これを書きながら思いましたが、これはCloud ArmorでIPアドレス範囲を利用してBackendServiceを保護している場合にも同じことが言えそうですね。
キャプチャは省略しますが、Cloud MonitoringのUptime checksの画面には、そのIPアドレス範囲が記されたテキストファイルをダウンロードできるボタンが設置されています。
中身を抜粋すると次のようなテキストファイルです。
{"ipAddress":"35.205.72.231","region":"EUROPE","location":"Belgium"},
{"ipAddress":"35.187.114.193","region":"EUROPE","location":"Belgium"},
{"ipAddress":"35.205.205.242","region":"EUROPE","location":"Belgium"},
{"ipAddress":"35.187.242.246","region":"ASIA_PACIFIC","location":"Singapore"},
{"ipAddress":"35.186.144.97","region":"ASIA_PACIFIC","location":"Singapore"},
{"ipAddress":"35.198.221.49","region":"ASIA_PACIFIC","location":"Singapore"},
{"ipAddress":"35.198.194.122","region":"ASIA_PACIFIC","location":"Singapore"},
...以下めっちゃたくさん続く
いやCIDRで指定できないんかい！
ヘルスチェックのsource IPアドレスはCIDRで2つ指定すれば終わるのに、これは違うんかい！
この記事は、ファイルさえあればあとはコマンドでなんとか設定できるのは理解しているんだけど、それを考えるのがめんどくさい人にたどり着いてもらうことが目的です。
jq コマンドがインストールされている環境を想定しています。
なお、筆者は fishシェルしか知りませんので、その他のシェルをお使いの方は適宜読み替えてください。
$ gcloud compute firewall-rules create allow-uptime-check-source \
--network=<network> --allow=<protocol>:<port> \
--source-ranges=(cat uptime-source-ips.txt | jq '.[].ipAddress' | tr -d '"' | tr '\n' ',')
ところで、このアドレスリストが常にUptime checksのIPアドレスであることは保証されているのだろうか。
例えばこれらのIPアドレスがいつか各リージョンで利用できる外部IPアドレスに変更される可能性があるのだとしたら...