1. 概要
このラボでは、Cloud Run サービスへのアクセスを制限し、オンプレミスまたはプロジェクトの VPC で実行されているワークロードからのリクエストのみを許可する方法について説明します。使用できるアクセス制御には、上り(内向き)設定と Identity and Access Management(IAM)ポリシーの 2 つのレイヤがあります。
上り(内向き)設定
上り(内向き)設定を使用すると、ネットワークの送信元(内部または外部)に基づいてリクエストをフィルタできます。デフォルトでは、公共のインターネットからのリクエストを含め、すべてのリクエストが通過できます。
IAM ポリシー
IAM ポリシーを使用すると、送信者の ID に基づいてリクエストをフィルタできます。IAM ポリシーは通常、サービス間のリクエストの認証に使用されます。
このラボでは、上り(内向き)設定を使用する方法と使用方法について学びます。
オンプレミス ホストは VPC 経由で接続する
このラボでは、オンプレミスのワークロードをシミュレートします。オンプレミス ホストを Cloud Run に接続するには、 オンプレミス ホスト用の限定公開の Google アクセスを構成します。以下に示すように、VPC ネットワークへの Cloud VPN ゲートウェイの設定も行います。
VPC でジャンプ サーバーを使用してオンプレミス ワークロードのシミュレーションを行う
このラボでは、以下に示すように VPC 内の Compute Engine 仮想マシンからリクエストを送信して、オンプレミス ホストからのリクエスト送信をシミュレートします。
ジャンプ サーバーとして使用する Compute Engine 仮想マシンのネットワーク オリジンは Cloud VPN ゲートウェイと同じであるため、これを使用してオンプレミス ワークロードからのリクエスト送信をシミュレートできます。
2. 設定と要件
セルフペース型の環境設定
- Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。
- プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。この値はいつでも更新できます。
- プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です(設定後は変更できません)。Cloud コンソールでは一意の文字列が自動生成されます。通常、それが何であるかは関係ありません。ほとんどの Codelab では、プロジェクト ID を参照する必要があります(通常は
PROJECT_ID
として識別されます)。生成された ID が気に入らない場合は、別のランダムな ID を生成できます。または、ご自身でお試しになることもできます。このステップを終えた後は変更できず、プロジェクト期間中は維持されます。 - なお、3 つ目の値は、一部の API で使用される [プロジェクト番号] です。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。
- 次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に課金されないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクト全体を削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
環境設定
- 後のコマンドで使用するために、環境変数にプロジェクト ID を設定します。
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export ZONE=us-central1-a
- このラボの実行に必要な API を有効にします。
gcloud services enable \
run.googleapis.com \
cloudbuild.googleapis.com \
compute.googleapis.com \
artifactregistry.googleapis.com
- サンプルアプリのリポジトリのクローンを作成し、以下のディレクトリに移動します。
git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git
cd cymbal-eats/partner-registration-service
- Compute Engine と Cloud Run のデフォルトのリージョンとゾーンを設定する
gcloud config set compute/region ${REGION}
gcloud config set run/region ${REGION}
gcloud config set compute/zone ${ZONE}
3. サービスをデプロイする
まず、サービスをデプロイし、一般公開したままにします。ブラウザからリクエストを送信できることを確認したら、Google はサービスをロックし、内部ネットワーク ソースからのリクエストのみを許可します。
次のコマンドを実行したら、次の操作を行います。
- ソースコードの場所(...): partner-registration-service ディレクトリにいることを確認し、Enter キーを押してデフォルトのままにします。
- サービス名(partner-registration-service): Enter キーを押してデフォルトを受け入れます
- [partner-registration-service] への未認証の呼び出しを許可しますか?(はい/いいえ)Y
gcloud run deploy
このコマンドが完了すると、Cloud Run サービスの URL が表示されます。出力は次のようになります。
Service [partner-registration-service] revision [partner-registration-service-00001-haz] has been deployed and is serving 100 percent of traffic. Service URL: https://partner-registration-service-ssssssssss-uc.a.run.app
ブラウザでサービス URL を開きます。以下のような出力が表示されます。
Partner registration service: RUNNING
内部リクエストのみを許可するようにサービスを設定する
次に、Cloud Run サービスの上り(内向き)設定を使用して、内部ソースからのリクエストのみを許可します。内部ソースには、Cloud Run サービスと同じプロジェクト(または VPC Service Controls の境界)にある VPC ネットワーク内のリソースが含まれるため、このユースケースに最適です。
また、他の Google Cloud プロダクトからのリクエストは、VPC の一部でなくても、内部とみなされます。このようなプロダクトとしては、Pub/Sub や Workflows などがあります。
これらのソースからのリクエストは、run.app URL でサービスにアクセスする場合でも Google ネットワーク内にとどまり、公開アクセスは禁止されています。
内部リクエストのみを許可するようにサービスを更新します。
gcloud run services update partner-registration-service --ingress=internal
サービスの URL をもう一度開くと、「Error: Forbidden - Access is forbidden」と表示されます。
ブラウザは、Google Cloud プロジェクト内部の送信元からではなく、外部のネットワーク送信元からリクエストを送信しているため、想定どおりの結果です。これでサービスのセキュリティが強化されました。
4. Compute Engine 仮想マシンをジャンプ サーバーとして作成する
次のステップでは、踏み台サーバーとして使用する Compute Engine インスタンスを VPC に作成して、Cloud VPN ゲートウェイを介したオンプレミス サーバーからのリクエストをシミュレートします。
gcloud compute instances create jump-server --scopes=https://www.googleapis.com/auth/cloud-platform
このコマンドの出力は次のようになります。
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS jump-server us-central1-a n1-standard-1 10.128.0.10 34.170.108.8 RUNNING
Compute Engine インスタンスからサービスにリクエストを送信する
次に、仮想マシンでターミナルを開き、VPC ネットワーク内のマシンから直接リクエストを送信します。
次のコマンドで、Cloud Shell で SSH を設定するように求められたら、次の手順を行います。
gcloud compute ssh jump-server
次のコマンドで Cloud Run サービスの URL を取得します。
gcloud run services describe partner-registration-service --region us-central1
出力の最初の数行は次のようになります。
✔ Service partner-registration-service in region us-central1 URL: https://partner-registration-service-ssssssssss-uc.a.run.app Ingress: internal
URL をコピーし、curl を使用して Compute Engine インスタンスからリクエストを送信します。VM インスタンスはプロジェクトの VPC ネットワーク(内部ソース)で実行されるため、このリクエストは成功するはずです。
export SERVICE_URL=https://
curl ${SERVICE_URL}
出力は次のようになります。
Partner registration service: RUNNING
5. IAM ベースのアクセス制御はどうなっていますか?
このラボでは、上り(内向き)設定を使用する方法と用途について学習しました。オンプレミスのワークロードを Cloud Run に接続する場合、上り(内向き)設定が最初のステップとして最適です。
IAM ベースのアクセス制御を実装するには、特にオンプレミス ホストから呼び出す場合、より多くの作業が必要になります。
- IAM では、有効期間が長いサービス アカウント認証情報をホストで管理する必要がある
- IAM では、サービス アカウントの認証情報を使用してリクエストに署名するコードを変更する必要があります。
アクセス制御には多層的なアプローチをおすすめします。上り(内向き)設定を使用してアクセスを内部ホストのみに制限することは、素晴らしい第一歩ですが、それだけではありません。
6. 完了
お疲れさまでした。これでこの Codelab は終了です。
次のステップ:
Cymbal Eats の他の Codelab を確認する:
- Eventarc を使用した Cloud Workflows のトリガー
- Cloud Storage からのイベント処理のトリガー
- Cloud Run から Private Cloud SQL への接続
- Cloud Run からフルマネージド データベースへの接続
- Identity-Aware Proxy(IAP)でサーバーレス アプリケーションを保護する
- Cloud Scheduler を使用した Cloud Run ジョブのトリガー
- Cloud Run への安全なデプロイ
- GKE Autopilot からプライベート AlloyDB への接続
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。
プロジェクトの削除
課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。
有用な参考資料
ここでは、Cloud Run の 2 つのアクセス制御レイヤについて理解を深めるために役立つ参考情報を紹介します。