カウシェにおける Cloud Run のネットワーク構成のこれまでとこれから
こんにちは、株式会社カウシェの Architect かつ Google Cloud Champion Innovator（Modern Architecture と Serverless App Development の分野）の伊藤です。
本稿では、Google Cloud が提供するサーバーレスなコンテナ実行環境である Cloud Run のネットワーク構成について、「カウシェにおける現状の構成」と「Cloud Run の新機能を利用した今後の改善」を解説します。
Cloud Run のサービス間通信
カウシェでは Cloud Run を用いてマイクロサービスを構築しています。
上図の場合、「Service A」は他のマイクロサービスからの通信を受け付ける必要はありますが、インターネットから直接通信を受け付ける必要はないので、Least Privilege の考え方に基づいてインターネットからの Service A へのアクセスを禁止すべきです。
Cloud Run にデプロイされたサービスはデフォルトではインターネットからアクセスが可能な状態になりますが、Ingress のネットワーク設定を変更することでサービスへのインターネットからのアクセスを禁止することもできます。具体的には、Cloud Run は下記の 3 つの Ingress の設定を提供しています:
- Internal
- 同一 VPC Network 内などの内部通信のみを許可
- 「内部通信」の定義については Ingress の設定に関するドキュメント に記載されています - Internal and Cloud Load Balancing
- 上記の「Internal」に加えて、External Application Load Balancer からの通信も許可 - All
- インターネットからの通信を含む、すべての通信を許可
カウシェのマイクロサービスは API Gateway Pattern を用いて構成しているので、すべての通信は External Application Load Balancer を経て API Gateway サービスが一次的に受け付けます。そのため、カウシェでの Cloud Run サービスの Ingress の設定は、API Gateway サービスだけが「Internal and Cloud Load Balancing」に設定されており、それ以外の全てのサービスは「Internal」に設定されています。これにより、不必要なインターネットからの Cloud Run サービスへのアクセスを遮断することが可能となります。
カウシェでは、Cloud Run のサービス間通信を「Internal」にするために、すべての Cloud Run サービスを VPC Network に所属させています。
Shared VPC Network と VPC Service Controls Perimeter
Google Cloud で VPC Network を構築する方法には、単一の Google Cloud Project 上に VPC Network とそれに所属するリソースを配置する「Single VPC Network」と、VPC Network とそれに所属するリソースを異なる Google Cloud Project 上に配置する「Shared VPC Network」の 2 つのパターンが存在します。
カウシェでは、Google Cloud が提供する VPC デザインに関する Best Practices を鑑みつつ、「VPC Network を Platform Team で一元的に管理したい」という考えから Shared VPC Network を採用しています。具体的には、VPC Network を管理するための専用の Google Cloud Project を Shared VPC Host Project として構築し、Cloud Run とその他のリソースは Shared VPC Service Project として異なる Google Cloud Project に配置しています。
この Shared VPC Network に Cloud Run サービスを所属させるため、Serverless VPC Access Connector を利用しています。Serverless VPC Access Connector は Cloud Run や Cloud Functions といったサーバーレス環境を VPC Network に接続させるためのコンポーネントです。Cloud Run サービスのデプロイ時に Serverless VPC Access Connector を利用するように設定し、Cloud Run サービスからの Egress 方向のすべての通信を Shared VPC Network を経由するように構築しています。
また、Shared VPC Network を経由する Cloud Run のサービス間通信を「Internal」扱いにするために、VPC Service Controls Perimeter を利用しています。VPC Service Controls Perimeter は Google Cloud 上のリソースから不正に情報が漏洩することを防止するための機能です。Cloud Run で Shared VPC Network を用いる場合、同一の VPC Service Controls Perimeter 内に Shared VPC Host Project と Shared VPC Service Project が配置されている場合にサービス間通信が「Internal」として扱われます。
まとめると、カウシェにおける Cloud Run のネットワークは、Shared VPC Network、Serverless VPC Access Connector、VPC Service Controls Perimeter を利用して下図のように構成されています。
今後の改善
Direct VPC Egress を用いた VPC Network への接続
カウシェでは Serverless VPC Access Connector を用いて Cloud Run サービスを VPC Network に接続していると解説しましたが、Serverless VPC Access Connector はそれ自体の死活監視などの管理コストを必要とします。2023 年 8 月にリリースされた Direct VPC Egress（この記事の執筆時点では Preview）を利用することで、この Serverless VPC Access Connector なしで Cloud Run を直接 VPC Network に接続させることが可能となりました。今後は Google Cloud が解説する各 VPC Network 接続方法のメリット・デメリットを鑑みつつ、Direct VPC Egress を用いたシンプルな構成で Cloud Run サービスを VPC Network に接続したいと考えています。
VPC Service Controls Perimeter を必要としない「Internal」なサービス間通信
Shared VPC Network を経由した Cloud Run のサービス間通信を「Internal」扱いにするために VPC Service Controls Perimeter を利用している、と解説しましたが、2023 年 4 月から VPC Service Controls Perimeter を利用しなくても Shared VPC Network を経由した通信が「Internal」として扱われるようになりました（2023 年 10 月にこの機能は GA になっています）。VPC Service Controls Perimeter は多重的な防御として有用ですが、権限管理や構築のコストが増えるので、セキュリティ的な懸念も考慮しつつ VPC Service Controls Perimeter を利用しない構成に変更しても良いのでは、と考えています。
おわりに
本稿では、カウシェにおける Cloud Run のネットワーク構成について、Cloud Run が提供するネットワークの機能の解説を交えつつ紹介しました。Cloud Run は、ネットワークの他にもサイドカーコンテナのサポートなど、便利な機能が続々とリリースされているので今後の機能追加も楽しみです。この記事が、みなさまの Cloud Run のネットワーク構築の一助となれば幸いです。それでは。
