このページは Cloud Translation API によって翻訳されました。

Cloud Run への安全なデプロイ

1. 概要

セキュリティを強化するために Cloud Run にサービスをデプロイするデフォルトの手順を変更してから、デプロイされたアプリに安全な方法でアクセスする方法を確認します。アプリが「パートナー登録サービス」であるこれは、Cymbal Eats と連携して料理の注文を処理する企業が使用する Cymbal Eats アプリケーションのものです。

学習内容

アプリを Cloud Run にデプロイする際のデフォルトの最小手順に少しの変更を加えることで、セキュリティを大幅に高めることができます。既存のアプリとデプロイの手順に沿ってデプロイ手順を変更し、デプロイ済みアプリのセキュリティを向上させます。

その後、アプリへのアクセスを認可し、認可されたリクエストを行う方法を確認します。

これは、アプリケーションデプロイのセキュリティを網羅した説明ではありません。わずかな労力でセキュリティを向上させる、将来のすべてのアプリケーションデプロイに加えることができる変更について説明します。

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 米ドル分の無料トライアルプログラムをご利用いただけます。

Cloud Shell をアクティブにする

Cloud Console で、[Cloud Shell をアクティブにする] をクリックします。

Cloud Shell を初めて起動する場合は、その内容を説明する中間画面（スクロールしなければ見えない範囲）が表示されます。その場合は、[続行] をクリックします（今後表示されなくなります）。この中間画面は次のようになります。

Cloud Shell のプロビジョニングと接続に少し時間がかかる程度です。

この仮想マシンには、必要な開発ツールがすべて含まれています。仮想マシンは Google Cloud で稼働し、永続的なホームディレクトリが 5 GB 用意されているため、ネットワークのパフォーマンスと認証が大幅に向上しています。このコードラボでの作業のほとんどは、ブラウザまたは Chromebook から実行できます。

Cloud Shell に接続すると、すでに認証は完了しており、プロジェクトに各自のプロジェクト ID が設定されていることがわかります。

Cloud Shell で次のコマンドを実行して、認証されたことを確認します。

gcloud auth list

コマンド出力

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

Cloud Shell で次のコマンドを実行して、gcloud コマンドがプロジェクトを認識していることを確認します。

gcloud config list project

コマンド出力

[core]
project = <PROJECT_ID>

上記のようになっていない場合は、次のコマンドで設定できます。

gcloud config set project <PROJECT_ID>

コマンド出力

Updated property [core/project].

環境設定

このラボでは、Cloud Shell コマンドラインでコマンドを実行します。通常はコマンドをコピーしてそのまま貼り付けることができますが、プレースホルダの値を正しい値に変更しなければならない場合があります。

後のコマンドで使用するために、環境変数にプロジェクト ID を設定します。

export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export SERVICE_NAME=partner-registration-service

アプリを実行する Cloud Run サービス API、NoSQL データストレージを提供する Firestore API、デプロイコマンドで使用する Cloud Build API、ビルド時にアプリケーションコンテナを保持するために使用する Artifact Registry を有効にします。

gcloud services enable \
  run.googleapis.com \
  firestore.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com

Firestore データベースをネイティブモードで初期化します。このコマンドは App Engine API を使用するため、先に有効にする必要があります。

このコマンドでは、App Engine のリージョン（使用しませんが、履歴上の理由から作成する必要があります）と、データベース用のリージョンを指定する必要があります。App Engine には us-central、データベースには nam5 を使用します。nam5 は米国のマルチリージョンロケーションです。マルチリージョンのロケーションでは、データベースの可用性と耐久性が最大化されます。

gcloud services enable appengine.googleapis.com

gcloud app create --region=us-central
gcloud firestore databases create --region=nam5

サンプルアプリのリポジトリのクローンを作成し、以下のディレクトリに移動します。

git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git

cd cymbal-eats/partner-registration-service

3. README を確認する

エディタを開き、アプリを構成するファイルを確認します。このアプリのデプロイに必要な手順を説明する README.md を確認します。手順によっては、暗黙的または明示的なセキュリティ上の判断が必要となる場合があります。ここで説明するように、これらの選択肢のいくつかは、デプロイ済みアプリのセキュリティを向上させるために変更します。

ステップ 3 - `npm install` を実行する

アプリで使用されているサードパーティソフトウェアの来歴と整合性を把握することは重要です。ソフトウェアサプライチェーンのセキュリティの管理は、Cloud Run にデプロイされたアプリだけでなく、あらゆるソフトウェアの構築に関連しています。このラボではデプロイに重点を置いているため、この領域については説明しませんが、このトピックは別途調査することをおすすめします。

ステップ 4、5 - `deploy.sh` を編集して実行する

この手順では、アプリを Cloud Run にデプロイし、ほとんどのオプションをデフォルトのままにします。このステップは、次の 2 つの方法でデプロイの安全性を高めるために、変更します。

未認証のアクセスは許可しないでください。データ探索中に試してみるのに便利な方法ですが、これは商用パートナーが使用するウェブサービスであり、常にユーザーを認証する必要があります。
API やリソースに必要以上に多くのアクセス権を持つデフォルトのサービスアカウントではなく、必要な権限のみを持つ専用のサービスアカウントをアプリケーションで使用するように指定します。これは最小権限の原則と呼ばれ、アプリケーションセキュリティの基本的な概念です。

手順 6 ～ 11 - サンプルウェブリクエストを作成して正しい動作を確認する

アプリケーションのデプロイで認証が必要になるため、リクエストにはリクエスト元の ID の証明を含める必要があります。これらのファイルを変更する代わりに、コマンドラインから直接リクエストを行います。

4. サービスを安全にデプロイする

deploy.sh スクリプトで、未認証のアクセスを許可しないことと、最小限の権限を持つ専用のサービスアカウントを使用するという 2 つの変更が、必要に応じて特定されました。

まず新しいサービスアカウントを作成してから、deploy.sh スクリプトを編集してそのサービスアカウントを参照して未認証のアクセスを禁止します。その後、変更したスクリプトを実行してサービスをデプロイしてから、変更した deploy.sh スクリプトを実行します。

サービスアカウントを作成し、Firestore/Datastore に必要なアクセス権を付与する

gcloud iam service-accounts create partner-sa

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:partner-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role=roles/datastore.user

`deploy.sh` の編集

deploy.sh ファイルを変更して未認証のアクセスを禁止し（–no-allow-unauthenticated）、デプロイ済みのアプリの新しいサービスアカウント（–service-account）を指定します。実際のプロジェクトの ID になるよう GOOGLE_PROJECT_ID を修正します。

次のように、最初の 2 行を削除し、残りの 3 行を変更します。

gcloud run deploy $SERVICE_NAME \
  --source . \
  --platform managed \
  --region ${REGION} \
  --no-allow-unauthenticated \
  --project=$PROJECT_ID \
  --service-account=partner-sa@${PROJECT_ID}.iam.gserviceaccount.com

サービスをデプロイする

コマンドラインから、deploy.sh スクリプトを実行します。

./deploy.sh

デプロイが完了すると、コマンド出力の最後の行に新しいアプリの Service URL が表示されます。URL を環境変数に保存します。

export SERVICE_URL=<URL from last line of command output>

次に、curl ツールを使用してアプリから注文を取得してみましょう。

curl -i -X GET $SERVICE_URL/partners

curl コマンドの -i フラグは、出力にレスポンスヘッダーを含めるように指示しています。出力の最初の行は次のようになります。

HTTP/2 403

アプリは、未認証のリクエストを拒否するオプション付きでデプロイされました。この curl コマンドには認証情報が含まれていないため、Cloud Run で拒否されます。実際にデプロイされたアプリケーションは、このリクエストの実行やデータの受信さえしません。

5. 認証済みリクエストを行う

デプロイされたアプリは、ウェブリクエストを行うことで呼び出されます。ウェブリクエストを許可するには、Cloud Run で認証を行う必要があります。ウェブリクエストは、次の形式の Authorization ヘッダーを含めることで認証されます。

Authorization: Bearer identity-token

ID トークンは、信頼できる認証プロバイダによって発行される、暗号で署名され、エンコードされた短期間の文字列です。この場合、Google が発行した期限切れでない有効な ID トークンが必要です。

ユーザーアカウントとしてリクエストを行う

Google Cloud CLI ツールは、デフォルトの認証済みユーザーにトークンを提供できます。次のコマンドを実行して、自分のアカウントの ID トークンを取得し、ID_TOKEN 環境変数に保存します。

export ID_TOKEN=$(gcloud auth print-identity-token)

デフォルトでは、Google が発行した ID トークンは 1 時間有効です。次の curl コマンドを実行して、許可されていないため以前に拒否されたリクエストを作成します。このコマンドには、必要なヘッダーが含まれます。

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $ID_TOKEN"

コマンド出力は HTTP/2 200 で始まります。これは、リクエストが受け入れられ、尊重されていることを示しています。（1 時間待ってからこのリクエストをもう一度試すと、トークンの有効期限が切れているため、リクエストは失敗します）。レスポンスの本文は、出力の最後、空白行の後にあります。

{"status":"success","data":[]}

パートナーはまだいません。

次の 2 つの curl コマンドで、ディレクトリにあるサンプル JSON データを使用してパートナーを登録します。

curl -X POST \
  -H "Authorization: Bearer $ID_TOKEN" \
  -H "Content-Type: application/json" \
  -d "@example-partner.json" \
  $SERVICE_URL/partner

と

curl -X POST \
  -H "Authorization: Bearer $ID_TOKEN" \
  -H "Content-Type: application/json" \
  -d "@example-partner2.json" \
  $SERVICE_URL/partner

登録済みのすべてのパートナーを表示するには、前の GET リクエストを繰り返します。

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $ID_TOKEN"

はるかに多くのコンテンツを含む JSON データが表示され、2 社の登録済みパートナーに関する情報が表示されます。

未承認のアカウントとしてリクエストを送信する

直前のステップで行われた認証済みリクエストは、認証されただけでなく、認証済みのユーザー（お客様のアカウント）が承認されたことによっても成功しました。つまり、そのアカウントにはアプリを呼び出す権限があったということです。すべての認証済みアカウントに対して、このような操作を行う権限があるわけではありません。

前のリクエストで使用されているデフォルトのアカウントは承認されています。このアカウントは、アプリを含むプロジェクトを作成し、そのアカウント内で Cloud Run アプリケーションを呼び出す権限をデフォルトで付与したアカウントであるためです。この権限は必要に応じて取り消すことができますが、本番環境アプリケーションに適しています。今すぐ行う代わりに、権限やロールが割り当てられていない新しいサービスアカウントを作成し、そのアカウントを使用して、デプロイされたアプリへのアクセスを試みます。

tester という名前のサービスアカウントを作成します。

gcloud iam service-accounts create tester

この新しいアカウントの ID トークンは、先ほどデフォルトのアカウントの ID トークンを取得するのとほぼ同じ方法で取得できます。ただし、この場合、デフォルトアカウントにサービスアカウントの権限を借用する権限が必要です。アカウントにこの権限を付与します。

export USER_EMAIL=$(gcloud config list account --format "value(core.account)")

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="user:$USER_EMAIL" \
  --role=roles/iam.serviceAccountTokenCreator

次のコマンドを実行して、この新しいアカウントの ID トークンを TEST_IDENTITY 環境変数に保存します。コマンドでエラーメッセージが表示された場合は、1 ～ 2 分待ってから再試行してください。

export TEST_TOKEN=$( \
  gcloud auth print-identity-token \
    --impersonate-service-account \
    "tester@$PROJECT_ID.iam.gserviceaccount.com" \
)

前と同じように認証済みウェブリクエストを行いますが、今回は次の ID トークンを使用します。

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $TEST_TOKEN"

リクエストは認証済みですが、認可されていないため、コマンド出力は再び HTTP/2 403 で始まります。新しいサービスアカウントには、このアプリを呼び出す権限がありません。

アカウントの承認

Cloud Run サービスに対してリクエストを行うには、ユーザーまたはサービスアカウントに Cloud Run サービスに対する Cloud Run 起動元ロールが必要です。次のコマンドを使用して、テスターサービスアカウントにロールを付与します。

export REGION=us-central1
gcloud run services add-iam-policy-binding ${SERVICE_NAME} \
  --member="serviceAccount:tester@$PROJECT_ID.iam.gserviceaccount.com" \
  --role=roles/run.invoker \
  --region=${REGION}

新しいロールが更新されるまで 1 ～ 2 分待ってから、認証済みリクエストを繰り返します。最初に保存してから 1 時間以上経過している場合は、新しい TEST_TOKEN を保存します。

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $TEST_TOKEN"

これで、コマンド出力は HTTP/1.1 200 OK で始まり、最後の行に JSON レスポンスが含まれます。このリクエストは Cloud Run で承認され、アプリで処理されました。

6. プログラムの認証とユーザーの認証

ここまでの認証済みリクエストでは、curl コマンドラインツールを使用しています。代わりに使用できるツールやプログラミング言語は他にもあります。ただし、認証された Cloud Run リクエストを、通常のウェブページを備えたウェブブラウザから行うことはできません。ユーザーがウェブページでフォームを送信するためのリンクまたはボタンをクリックしても、ブラウザは認証済みリクエストに必要な Cloud Run の Authorization ヘッダーを追加しません。

Cloud Run の組み込みの認証メカニズムは、エンドユーザーではなくプログラムによる使用を想定しています。

注:

Cloud Run ではユーザー向けのウェブアプリケーションをホストできますが、この種のアプリケーションでは、ユーザーからの未認証リクエストを許可するように Cloud Run を設定する必要があります。できます。アプリケーションでユーザー認証が必要な場合は、Cloud Run にユーザー認証を要求する代わりに、アプリケーションでユーザー認証を処理する必要があります。これは、Cloud Run 外部のウェブアプリケーションと同じ方法で実行できます。その方法については、この Codelab の範囲外です。

ここまで、リクエスト例に対するレスポンスはウェブページではなく JSON オブジェクトでした。というのも、このパートナー登録サービスはプログラムで使用することを意図しており、JSON はプログラムにとって使いやすい形式だからです。次に、このデータを使用および使用するためのプログラムを記述して実行します。

Python プログラムからの認証済みリクエスト

プログラムは、標準の HTTP ウェブリクエスト（ただし Authorization ヘッダーを含む）を介して、保護された Cloud Run アプリケーションの認証済みリクエストを行うことができます。これらのプログラムにおける唯一の新しい課題は、有効期限が切れていない有効な ID トークンを取得してヘッダーに配置することです。このトークンは、Google Cloud Identity and Access Management（IAM）を使用して Cloud Run によって検証されるため、IAM によって認識される認証機関によって発行され、署名されている必要があります。多くの言語で利用可能なクライアントライブラリがあり、プログラムはこのトークンの発行をリクエストできます。この例で使用するクライアントライブラリは、Python の google.auth です。一般的に、ウェブリクエストを行うための Python ライブラリがいくつかあります。この例では、一般的な requests モジュールを使用しています。

まず、2 つのクライアントライブラリをインストールします。

pip install google-auth
pip install requests

デフォルトユーザーの ID トークンをリクエストする Python コードは次のようになります。

credentials, _ = google.auth.default()
credentials.refresh(google.auth.transport.requests.Request())
identity_token = credentials.id_token

お使いのパソコンで Cloud Shell や標準のターミナルシェルなどのコマンドシェルを使用している場合は、そのシェル内で認証されたユーザーがデフォルトのユーザーになります。Cloud Shell では通常、ユーザーは Google にログインしています。それ以外の場合は、gcloud auth login または他の gcloud コマンドで認証されたユーザーになります。ユーザーがログインしたことがない場合は、デフォルトユーザーは存在せず、このコードは失敗します。

プログラムが別のプログラムをリクエストする場合、一般的には個人の ID ではなく、リクエスト元のプログラムの ID を使用します。そのような場合のために、サービスアカウントがあります。Cloud Firestore などの API リクエスト時に使用する ID を提供する専用のサービスアカウントで Cloud Run サービスをデプロイしました。プログラムが Google Cloud Platform で実行されると、クライアントライブラリは自動的にそのプログラムに割り当てられたサービスアカウントをデフォルトの ID として使用するため、どちらの状況でも同じプログラムコードを使用できます。

Authorization ヘッダーを追加してリクエストを行う Python コードは次のようになります。

auth_header = {"Authorization": "Bearer " + identity_token}
response = requests.get(url, headers=auth_header)

次の完全な Python プログラムは、Cloud Run サービスに認証済みのリクエストを送信し、登録されているすべてのパートナーを取得してから、名前と割り当てられた ID を出力します。以下のコマンドをコピーして実行し、このコードを print_partners.py ファイルに保存します。

cat > ./print_partners.py << EOF
def print_partners():
    import google.auth
    import google.auth.transport.requests
    import requests

    credentials, _ = google.auth.default()
    credentials.refresh(google.auth.transport.requests.Request())
    identity_token = credentials.id_token

    auth_header = {"Authorization": "Bearer " + identity_token}
    response = requests.get("${SERVICE_URL}/partners", headers=auth_header)

    parsed_response = response.json()
    partners = parsed_response["data"]

    for partner in partners:
        print(f"{partner['partnerId']}: {partner['name']}")


print_partners()
EOF

このプログラムはシェルコマンドを使用して実行します。まず、デフォルトユーザーとして認証し、プログラムがこれらの認証情報を使用できるようにする必要があります。以下の gcloud auth コマンドを実行します。

gcloud auth application-default login

手順に沿ってログインを完了します。次に、コマンドラインからプログラムを実行します。

python print_partners.py

出力は次のようになります。

10102: Zippy food delivery
67292: Foodful

あなたの ID で認証されたため、プログラムのリクエストは Cloud Run サービスに到達しました。あなたはこのプロジェクトのオーナーであり、デフォルトでこのサービスを実行する権限を持っています。このプログラムは、より一般的にはサービスアカウントの ID で実行されます。Cloud Run や App Engine など、ほとんどの Google Cloud プロダクトで実行する場合、デフォルトの ID はサービスアカウントになり、個人アカウントの代わりに使用されます。

7. 完了

お疲れさまでした。これでこの Codelab は終了です。

次のステップ:

Cymbal Eats の他の Codelab を確認する:

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除

課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

Cloud Run への安全なデプロイ

1. 概要

学習内容

2. 設定と要件

セルフペース型の環境設定

Cloud Shell をアクティブにする

環境設定

3. README を確認する

ステップ 3 - npm install を実行する

ステップ 4、5 - deploy.sh を編集して実行する

手順 6 ～ 11 - サンプル ウェブ リクエストを作成して正しい動作を確認する

4. サービスを安全にデプロイする

サービス アカウントを作成し、Firestore/Datastore に必要なアクセス権を付与する

deploy.sh の編集

サービスをデプロイする

5. 認証済みリクエストを行う

ユーザー アカウントとしてリクエストを行う

未承認のアカウントとしてリクエストを送信する

アカウントの承認

6. プログラムの認証とユーザーの認証

Python プログラムからの認証済みリクエスト

7. 完了

次のステップ:

クリーンアップ

プロジェクトの削除

ステップ 3 - `npm install` を実行する

ステップ 4、5 - `deploy.sh` を編集して実行する

手順 6 ～ 11 - サンプルウェブリクエストを作成して正しい動作を確認する

サービスアカウントを作成し、Firestore/Datastore に必要なアクセス権を付与する

`deploy.sh` の編集

ユーザーアカウントとしてリクエストを行う