Cloud Run 上のプライベート ワークロードでユーザーを承認する 3 つの新しい方法

※この投稿は米国時間 2023 年 5 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

現在、Cloud Run を使ってアプリケーションを構築する組織が続々と増えてきています。Cloud Run は、Google のインフラストラクチャ上でコンテナ化したアプリケーションを実行できるようにする、フルマネージドのコンピューティング プラットフォームです。たとえば、ウェブ アプリケーションや、リアルタイムのダッシュボード、API、マイクロサービス、バッチデータ処理、テストおよびモニタリング ツール、データ サイエンス推論モデルまで、さまざまなものに活用できます。このたび、Cloud Run で社内用アプリケーションを構築する際に役立つ機能が追加されました。この投稿では、3 つの一般的な設計パターンを取り上げて、それらのパターンの実装に役立つ Cloud Run の新機能を紹介します。

1. 社内用ウェブアプリ - 一般提供が開始された Identity-Aware Proxy をご活用ください

2. 内部 API - 一般提供が開始されたリージョン内部 HTTP(S) ロードバランサをご活用ください

3. 共有 VPC にまたがるマイクロサービス - 公開プレビュー版がリリースされた共有 VPC の上り（内向き）をご活用ください

1. 社内用ウェブ アプリケーション

多くの組織でよくあるケースは、従業員のみがアクセスする社内用ウェブ アプリケーションを構築するというものです。このようなアプリケーションでは、これまで VPN 経由のカスタム認証フローを使用する必要がありましたが、これは理想的とはいえませんでした。このたび Identity-Aware-Proxy（IAP）が Cloud Run に対応し、一般提供が開始されたのに伴い、ログイン処理が簡略化され、アクセス制御を一元化できるようになりました。

Identity-Aware Proxy では、OAuth 2.0 および OpenID Connect の標準に従ってユーザーの認証、認可を行い、Google Cloud やその他のクラウド プラットフォーム上で実行されているアプリケーションへの安全なアクセスを実現しています。この方式を利用することは、ゼロトラストの原則への移行にもつながります。今後は、Cloud Run 上で実行されているウェブ アプリケーションでも IAP を使用して、クライアントのユーザー ID およびコンテキストに基づいてアクセスを認可することが可能になります。これにより、ログイン処理を簡略化できるほか、セキュリティ管理者は社内用ウェブ アプリケーションへのアクセスを一元管理することができます。特に機密性を重んじる組織の場合は、BeyondCorp Enterprise にアップグレードして、ユーザーおよびデバイスのコンテキストを含むフル コンテキストアウェア アクセスを IAP で有効にして、Cloud Run アプリケーションへのアクセスを制御できます。

今回のインテグレーションにおいて特筆すべき点は、IAP サービスそのものが、Cloud Run に組み込みの IAM システムから認証を受けるようになっているところです。具体的には、IAP が Cloud Run にリクエストを転送する際、自身のサービス アカウントの OpenID Connect ID トークンを X-Serverless-Authorization ヘッダーに含めます。これにより、Cloud Run 側で Cloud Run 起動元ロールを「allUsers」に与える必要がなくなります。これまで、共有をドメインで制限している組織ポリシーでは、このようなロールの与え方がネックになっていましたが、今回の一般提供開始により、Cloud Run 起動元ロールを IAP のサービス アカウントに与えるだけでよくなります。

2. 内部 API

Cloud Run は、簡単、安全、費用対効果が高いという特長を兼ね備えており、API の構築にも非常に適しています。公開 API には、カスタム ドメイン、高度なトラフィック管理、多くのセキュリティ機能をサポートしている外部 HTTP(S) ロードバランサを使用できます。一方、内部 API には、一般提供が開始されたリージョン内部 HTTP(S) ロードバランサを使用できます。リージョン内部 HTTP(S) ロードバランサは、外部 HTTP(S) ロードバランサの利点を内部ワークロード向けに提供するものであり、複数のプロジェクトにまたがるワークロードにも対応します。

外部ロードバランサと異なり、内部 HTTP(S) ロードバランサには VPC 上の他のリソースからしかアクセスできません。この仕組みによって、すべてのトラフィックが VPC 内にとどまることになり、クライアントは Cloud Run サービスをパブリック IP 経由で呼び出す必要がなくなります。アクセスをさらに制限するためには、上り（内向き）を「内部」に設定します。これにより、公共インターネットから Cloud Run サービスへのトラフィックをブロックできます。

3. 共有 VPC にまたがるマイクロサービス

共有 VPC にまたがるマイクロサービス モデルをご使用の場合は、サービス間の直接呼び出しを簡単に行えるようにしながら、全トラフィックがプライベート ネットワーク内に確実にとどまるような仕組みをお求めではないでしょうか。

そういったケースに最適なのが、このたび公開プレビュー版となった Cloud Run における共有 VPC の上り（内向き）です。これにより、Cloud Run を共有 VPC で使用するために必要な設定が簡単になりました。これまで、Cloud Run の上り（内向き）を「内部」に制限した場合、共有 VPC 内のサービス プロジェクトからのトラフィックはブロックされていました。今後は、上り（内向き）を「内部」または「内部と Cloud Load Balancing」として構成した場合でも、Cloud Run サービスのリビジョンが接続先の共有 VPC ネットワークからのリクエストを受け入れるようになります。  

Cloud Run と共有 VPC を使えば、アプリケーションをすばやく簡単に構築、デプロイできます。それに加えて今後は、ネットワークの一元管理や、セキュリティおよびスケーラビリティの向上といったメリットも得られるようになります。

次のステップ

Google は、セキュリティが最重要課題であることを認識しています。そのため、Cloud Run 上のアプリケーションのセキュリティ構成に役立つセキュリティ ガイドを公開しています。このガイドでは、Cloud Run の内部アーキテクチャ、データが処理される仕組み、セキュリティ要件を満たすために役立つ機能を紹介しています。

Infrastructure as Code を使用して既存のシステムにこのアーキテクチャを組み込む手軽な方法をお探しの方向けに、進化を続ける Terraform ブループリント一式も公開しています。