FireWallルールについての記事になります。GCPで共有VPC環境を構築していると通常のGCP環境構築に比べて考慮する点が多く、FireWallは特に苦労したポイントの一つです。そんなFireWallの設計について実例ベースに書いていきたいと思います。前述の通り、構築する環境はGCPで共有VPCを利用した環境になります。仮に10.14.0.0/16のアドレス範囲を利用するとして、以下のようにサブネットとプロジェクトを構築しています。※詳細は以前の記事を参照。各プロジェクト(環境)毎にサブネットを割り当てているCloudSQLインスタンスはすべてのプロジェクトで同じアドレス範囲を利用する※CloudSQLインタンスを作成するインタンスのアドレス範囲はVPCに紐づくため共有VPCで1つのためhttps://cloud.google.com/sql/docs/mysql/private-ip#network_requirementsGCPのFireWallについて実際の設計をする前にFireWallの設定項目について説明します。一致したときのアクション(allowとdeny)FireWallのルールは特定の通信をallow(許可)/deny(拒否)する設定になります。前項のallow/denyしたルールの優先度を設定します。これにより「全体に対しての通信は拒否するが一部のみ許可」のような設定が可能になります。「上り」か「下り」が設定できます。FireWallのルールを設定するVMインスタンスに対しFromの通信なのかToの通信なのかを定義できます。アカウントによるインスタンス」で指定できます。後述しますが、サブネットでの指定はできません。暗黙ルール前項の上りに関しては暗黙(最低優先度)でdenyの設定が、下りに関してはallowの設定が入っています。実際に設計してみるでは実際に設計してみます。今回は以下の2観点で分けて設計します。VMインスタンスVMインタンスについては以下の2つを実現する必要がありました。各プロジェクト(環境)を跨いだ通信ができないようにする。VPC外のアドレス(インターネットVPN経由でのオンプレ環境)からの通信は全て可能とする。順を追って設計してみましょう。ブラックリストかホワイトリストかまずは考え方の方針として、ブラックリストかホワイトリストかを決めます。今回はホワイトリストを意識させる方式にしました。これはブラックリストにすると、とあるプロジェクトにインスタンス追加したときに他プロジェクトすべてに対してそのインスタンスを意識する必要が出てきてしまうためです。ホワイトリストにすることで、自プロジェクトのみ意識すればよくなります。全てのアドレスからの通信を許可するでは次に実際の設定を入れていきます。前述の通り、上りに関しては暗黙(最低優先度)でdenyの設定が入っているため、VMインスタンスは基本的にどことも通信できないです。優先度:1000これでまずは外部、内部の全ての通信が可能となります。インスタンス間の通信をすべてNGとする次にVMインスタンス間の通信を全て拒否します。今の状態だとプロジェクトも跨いだ(ProductionとStaging間等)通信が可能な状態です。ここでもProduction環境に対してがProduction環境のサブネット以外を拒否が出来れば良いのですが、前述の通り「以外」の設定ができないため、まずはホストのVPC(10.14.0.0/16)に対して全ての通信を拒否します。優先度:900ここでは前述の設定よりも優先度を高くすることで以下のようになります。同じプロジェクトのインスタンスの通信を許可する最後に同一のプロジェクトのインスタンス間の通信を許可します。これを実現するため、各インスタンスにはプロジェクトごとに共通のネットワークタグを設定します。※仮にProduction環境のインスタンスについて「prd-instance」とタグをつけるとします。優先度:500これで各プロジェクト内での通信が可能となりますこれをStagingなど他環境にも設定することで各プロジェクト内での通信が可能となります。CloudSQLインスタンス次にCloudSQLインスタンスへのアクセスを設定したいと思います。前述の通り、CloudSQLインスタンスはすべてのプロジェクトで同じアドレス範囲を利用するため、アドレス範囲を指定してのキレイな指定はできません。何対してFireWallルールを設定するかSQLインスタンスにはネットワークタグは付けれないため、FireWallルールはVMインスタンスについて設定することになります。先ほどは上りに対しての設定でしたが、VMインスタンスからCloudSQLの通信を制御するため、こちらでは下りの制御を入れます。全てのSQLインスタンスに対して通信を拒否するまず、下りの通信は暗黙のルールでallowになっているため、どのVMからでもすべてのSQLインスタンスに接続できます。このため、まずはすべてのVMインスタに対してSQLインスタンスに割り当てられるアドレス範囲の通信を拒否します。優先度:500これで全てのVMインスタンスとSQLインスタンスで通信が出来なくなります。特定のSQLインスタンスに対して通信を許可する次に同一プロジェクトのVMインスタンスとSQLインスタンスの通信を許可します。この際、SQLインタンスはアドレス範囲内でランダムのため、アドレス範囲の指定ではなく、インスタンスのIPそのものを指定する必要があります。Production環境を例にとると以下の通りです。優先度:100これで同一プロジェクトのVMインスタンスとSQLインスタンスのみで通信が可能となります。この際、SQLインスタンスのアドレスはインタンス名から取得するようにTerraformやスクリプトなど組んでおくように注意しましょう。IPアドレスはインタンスの再作成で変わるため定義としての再現性はありません。まとめ今回はネットワーク構成を起点にFireWallルールを設定するというオンプレ的な設計をしてみました。サービスアカウントなどをうまく使えばもっとシンプルな設計も出来たかもしれませんが、そのあたりの設計が固まっていなくても下回りで保証する一例として見てもらえると幸いです。upLoginユーザーは見つかりませんでした。