はじめに
この記事は、
SRE ディビジョンの新卒向け研修に取り組んだ話
という記事を読んで、その成果物となる一部の構成に
注目して自身の環境で『実際にやってみた』という記事になります。
この記事で実施する事。
-
Cloud Run Serviceをデプロイする。 -
Cloud Load Balancingをデプロイする。 -
Cloud Armorをデプロイする。 - 地理制限とトラフィックの分散を確認する。
今回はタイトルにもあるように、以下の範囲を実践します。
Cloud Run Service をデプロイする。
get-current-time を、git clone してください。
git clone https://github.com/tomo8332/gcp-sample.git
git cloneの実行が完了したら、cdコマンドを使って、対象のディレクトリ階層へ移動。
cd gcp-sample/cloud-run/golang/get-current-time
README.md を読んで、Cloud Run サービスのデプロイを行なってください。
今回は、トラフィックが分散されている事を確認したいので、
少なくとも2つ以上の異なるリージョンにデプロイしてください。
Cloud Load Balancing をデプロイする。
GCPコンソールを開いて、『load balancing』を検索。
ロードバランサを作成をクリック。
アプリケーション ロードバランサ（HTTP/S）の『構成を開始』をクリック。
適切なロードバランサのタイプを選択。
新しいフロントエンドを作成。
名前：cloud-armor-cloud-run-frontend
プロトコル：https
証明書を作成。
名前：任意の名前を入力。
作成モード：Google マネージドの証明書を作成する
ドメイン：お名前.com などのドメイン登録サービスで取得したドメインを入力。
フロントエンドの設定は、その他の項目はデフォルトで完了。
バックエンドの構成 > バックエンドサービスを作成。
新しいバックエンドサービスを作成。
名前：cloud-armor-cloud-run-backend
バックエンドタイプ：サーバーレス ネットワーク エンドポイント グループ
バックエンドのサーバレスネットワークエンドポイントグループを選択。
既存で作成していれば、対象のサーバレスネットワークエンドポイントグループを選択。
作成していない場合は、新規でサーバレスネットワークエンドポイントグループを作成。
サーバーレス ネットワーク エンドポイント グループの作成。
名前：任意の名前を入力。
リージョン： Cloud Run Service をデプロイしているリージョンを選択。
サービス：バックエンド対象のCloud Run Service を選択。
バックエンドは、Cloud Armor で地理制限を行い、
Cloud Load Balancing で、分散したいので、
異なるリージョンにデプロイされた
２つ以上の Cloud Run で構成された
サーバレスNEGを選択してください。
バックエンドサービスの以下の設定を変えて、作成をクリック。
『Cloud CDN を有効にする』> チェックを外す。
『ロギングを有効にする』> チェックを入れる。
今回は、検証環境での実装の為、この条件としています。
ルーティングルールを設定。
モード：単純なホストとパスのルール
ホストとパスのルールで、バックエンドとそのバックエンドに
ルーティングするためのホストとパスを入力。
ロードバランサの名前を入力して、ロードバランサを作成。
ブラウザを開いて、ホストとパスを入力、Cloud Run Service に接続ができればOK。
Cloud Armor をデプロイする。
GCPコンソールを開いて、『cloud armor』を検索。
『ポリシーの作成』をクリック。
ポリシーの構成
名前：cloud-armor-cloud-run
ポリシータイプ：バックエンド セキュリティ ポリシー
範囲：グローバル
デフォルトのルールアクション：拒否
レスポンスコード：403（アクセス拒否）
これは、次のステップで登録するルールに一致しない場合、
グローバルの範囲でデプロイされたリソースに対して、実行内容を拒否する。
つまりは、『ルールに一致しないリクエストを拒否する』ということである。
ルールの追加
モード：詳細設定
ルール構文に、下記をペースト。
origin.region_code == 'JA'
これは、特定のリージョンからのトラフィックを許可するルールを構築。
カスタムルール言語属性の構成は、下記を参照。
ルールの追加の続き。
アクション：許可
優先度：0
特定のリージョンからのトラフィックを許可するルールを
設定しているので、アクションは 許可 を選択。
また、新規で別のルールを作成、
新規のルールの方が優先度が高い場合は、
- 新規のルールの優先度は、
0に修正 - 既存のルールの優先度は、
1に修正
が必要となる。
Cloud Armor では、優先度の数値が
小さいほど優先度が高いと見なされる。
ターゲットへのポリシーの適用。
今回は、Cloud Load Balancing のバックエンドサービスに対して、
ポリシーを適用するので、対象のバックエンドサービスを選択。
ポリシーの構成とルールの追加、ターゲットの選択を終えたら、ポリシーの作成を実行。
地理制限とトラフィックの分散を確認する。
下記のガイドに従って、Compute Engine で Linux VM インスタンスを作成する。
なお、VMインスタンスは検証の為、3つ作成する。
名前：
1つ目のインスタンス：asia-northeast1-vm
2つ目のインスタンス：asia-northeast2-vm
3つ目のインスタンス：us-west2-vm
リージョン：
1つ目のインスタンス：asia-northeast1
2つ目のインスタンス：asia-northeast2-
3つ目のインスタンス：us-west2
ゾーンはデフォルト
マシンの構成
シリーズ：E2
マシンタイプ：e2-micro
を選択。
ブートディスクの構成はガイドに沿って設定する。
ファイアウォールは、
- HTTPS トラフィックを許可する
- HTTPS トラフィックを許可する
にチェックを入れて、VMインスタンスを作成する。
それぞれのVMインスタンスで SSH 接続を行い、Curl コマンドでリクエストを送信。
海外リージョン でデプロイされたVMで、Curl コマンドを実行した際に、
地理制限 が反映されていれば、Cloud Armor の設定は完了。
トラフィックの分散では、それぞれの条件を満たしていれば設定は完了。
asia-northeast1 リージョンにデプロイされたVMで、
Curl コマンドを実行した際は、 asia-northeast1 にトラフィックが分散。
asia-northeast2 リージョンにデプロイされたVMでは、
Curl コマンドを実行した際は、 asia-northeast2 にトラフィックが分散。
終わりに
今回の記事は、SRE ディビジョンの新卒向け研修に取り組んだ話
という記事で書かれていた内容から、その一部の構成として、
まだ、私があまり触れたことのないCloud Armor に注目して、
自身の環境で『実際にやってみた』という内容でまとめました。
今回、Cloud Armor の設定では、地理制限のみがかけられていますが、
これ以外の設定として、自宅IPからのアクセスのみを許可する事や、
特定のIPアドレスからのリクエスト数が一定の閾値を超えた場合に
制限をかけたり、また、特定のIPアドレス範囲、HTTPヘッダーや、
その他のリクエスト属性に基づいてトラフィックを許可または拒否が可能で、
分散型サービス拒否（DDoS）攻撃の軽減、SQLインジェクションや
クロスサイトスクリプティング（XSS）などの一般的なウェブベースの
攻撃から、アプリケーションの保護などを行ってくれる優れ物みたいです。
Cloud Armor について、
軽く学習してみたいと考えていましたら、
参考にしていただけると幸いです。
あとで『じっくり読みたい』、『繰り返し読みたい』と
思ってくれましたら、『ストック』へ登録、
この記事が読まれている方にとって、
参考になる記事となりましたら、『いいね』を
付けていただけますと、励みになりますので、
よろしくお願いします。