割と最近熱かった案件で
- 既存のWebサイトに特設キャンペーンサイトを追加で作りたい！ ※要件1
- CM打ったりしてすげーアクセス来るからサーバ別がいいな ※要件2
- 開発環境じゃなくて本番でチェックしたい！でも時間になるまで開けちゃダメよ ※要件3
みたいな点をクリアするのに、サーバ毎にIP許可を入れるっていうんじゃない方法で対応したのでそのメモ
CloudArmor ってザックリ言うとなに？
- GCPのロードバランサにくっついてるセキュリティ機能
ザックリすぎるよ
まあ細かい話は置いといて今回は、LBを通す通信にはIP制限を入れられない。という困ったGCP LBの問題点をクリアするために使いました。
AWSのELBであれば
- ホワイトリスト形式での許可
- ACLでのブラックリスト設定
などなど設定できるのに対してGCPのFWはインスタンスに対してのアクセス制限しかできず、Apacheやnginx側で上手いこと処理する必要がありました。
それがCloudArmorを使うことによってロードバランサ内で弾くことができるようになり、DoS攻撃も許可されてないアクセスもWebサーバに負荷をかけなくなりました！
※ StackDriverLoggingで、ロードバランサのログを覗けば弾いたログは見えます
#####文字でダラダラ書いても解りづらいので図解！
え？もっと解りづらい？
そんなぁ・・・
#####一応解説！
- まず要件1を満たすために同じドメインである必要があるので、既存LBのFrondendはいじりません。
- 要件2を満たすため、HTTPSロードバランサのHost and path rulesを使い、キャンペーンサイトだけ別のBackendServiceへ逃がします。
- このBackendServiceにぶら下がる各InstanceGroupには、既存メインもキャンペーンも同一のWebサーバが入ります。容量は多少無駄になりますがデプロイを分ける必要がなくなります。
- そして最後！要件3を満たすためにチェックするオフィスから以外のアクセスを弾きます。
- この弾く場合の挙動、403とか404とか好きに表示できるのでお好みで。
- ポイントとして、CloudArmorのポリシーは、BackendServiceに対して効きます。
余談：初めて見たときPriority 2と147と483と647 ってなんでデフォルト挙動に沢山割り振られてるんだ・・・？って10秒考えて21億ちょいでintの限界って気づいた。どんだけ設定させるつもりだよ
大体以上！
あとは時間に合わせてCloudArmorのPoliciesを消してしまえばオープンとなります。
一回この構成を作ってしまえば、広告期間終わって流入が落ち着いてもHost and path rulesを消すとMainBackendにトラフィックは流れます。
あるいは第二弾キャンペーンも分けたいな！ってなったらルールを追加してcampaign0002を作ったり、CloudArmorのPoliciesを足したり対応可能。