サービス ID

Cloud Run のすべてのリビジョンまたはジョブがサービスアカウントにリンクされています。このサービスアカウントは、Google Cloud APIs での認証を行うために Google Cloud クライアントライブラリによって自動的に使用されます。サービスのコードで利用できる Google Cloud APIs の例として、Cloud Storage、Firestore、Cloud SQL、Pub/Sub、Cloud Tasks などが挙げられます。

サービスアカウントの指定がない場合、Cloud Run はすべての Google Cloud APIs に対して幅広い権限を持つデフォルトのサービスアカウントにリビジョンまたはジョブをリンクします。Google では、サービスごとの ID を使用して、選択的な権限を付与することをおすすめします。

デフォルトのサービスアカウントについて

デフォルトでは、Cloud Run のリビジョンとジョブは Compute Engine のデフォルトのサービスアカウントとして実行されます。Compute Engine のデフォルトのサービスアカウントには、Google Cloud プロジェクト内のすべてのリソースに対して読み取りと書き込みの権限を付与するプロジェクト編集者の IAM ロールが設定されています。

デフォルトのサービスアカウントが便利な場合もありますが、きめ細かい権限を持つ独自のユーザー管理サービスアカウントを作成し、そのサービスアカウントを Cloud Run サービスまたはジョブの ID として割り当てることをおすすめします。このドキュメントでは、Cloud Run でサービスごとの ID を構成する方法について説明します。

サービスごとの ID の使用

デフォルトのサービスアカウントを使用する代わりに、ユーザー管理サービスアカウントを割り当てることにより、すべての Cloud Run サービスまたはジョブに専用 ID を与えることをおすすめします。ユーザーが管理するサービスアカウントでは、Identity and Access Management を使用して最小限の権限セットを付与することでアクセスを制御できます。

Google Cloud CLI と Google Cloud クライアントライブラリは、Google Cloud での実行を自動的に検出し、現在の Cloud Run リビジョンのランタイムサービスアカウントを使用します。つまり、コードが gcloud CLI または公式の Google Cloud クライアントライブラリを使用する場合、Cloud Run サービスのランタイムサービスアカウントとして自動的に検出され、認証されます。この方法はアプリケーションのデフォルト認証情報と呼ばれ、複数の環境にコードを移植できます。

サービスごとの ID の割り当てには、次の 2 つの側面があります。

サービスごとの ID を割り当てるために必要な権限
割り当てられた ID 自体が機能するために必要な権限

ユーザーが管理するサービスアカウントを割り当てるために必要な権限

ユーザー管理サービスアカウントを使用して Cloud Run サービスをデプロイするには、そのサービスアカウントの権限を借用できる権限（iam.serviceAccounts.actAs）が必要です。この権限は、roles/iam.serviceAccountUser IAM ロールを介して付与できます。ユーザー管理サービスアカウントとして Cloud Run サービスをデプロイするには、すべてのプリンシパル（ユーザー、サービスアカウントなど）がユーザー管理サービスアカウントに対する権限を持っている必要があります。

この権限は、Google Cloud コンソール、API（YAML）または gcloud CLI を使用して付与できます。手順は次のとおりです。

gcloud iam service-accounts add-iam-policy-binding "SERVICE_ACCOUNT_EMAIL" \
    --member "PRINCIPAL" \
    --role "roles/iam.serviceAccountUser"

次のように置き換えます。

SERVICE_ACCOUNT_EMAIL は、サービスアカウントのメールアドレスに置き換えます（PROJECT_NUMBER-compute@developer.gserviceaccount.com など）。
PRINCIPAL は、バインディングを追加するプリンシパルに置き換えます。user:email の形式を使用します（例: user:test-user@gmail.com）。

権限を付与する方法については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。

ユーザーが管理するサービスアカウントで新しいサービスをデプロイする

ユーザー管理サービスアカウントがない場合は、まずサービスアカウントを作成します。

Cloud Run サービスのサービスアカウントは、新しいサービスを作成するとき、または新しいリビジョンをデプロイするときに、Google Cloud コンソール、gcloud CLI、または API（YAML）を使用して設定できます。

コンソール

Google Cloud コンソールで、[Cloud Run] に移動します。

Cloud Run に移動
デプロイ先の新しいサービスを構成する場合は、[サービスを作成] をクリックします。既存のサービスを構成する場合は、サービスをクリックし、[新しいリビジョンの編集とデプロイ] をクリックします。
新しいサービスを構成する場合は、最初のサービス設定のページに入力してから、[コンテナ、ボリューム、ネットワーキング、セキュリティ] をクリックしてサービス構成ページを開きます。
[セキュリティ] タブをクリックします。
- [サービスアカウント] プルダウンをクリックして、目的のサービスアカウントを選択します。
[作成] または [デプロイ] をクリックします。

gcloud

次のコマンドを使用して、新しいランタイムサービスアカウントを使用するように既存サービスを更新できます。

gcloud run services update SERVICE --service-account SERVICE_ACCOUNT

次のように置き換えます。

SERVICE は、実際のサービスの名前に置き換えます。
SERVICE_ACCOUNT は、新しい ID に関連付けられたサービスアカウントに置き換えます。この値は、サービスアカウントのメールアドレス（example@myproject.iam.gserviceaccount.com など）です。

また、デプロイ中に次のコマンドを使用してサービスアカウントを設定することもできます。

gcloud run deploy --image IMAGE_URL --service-account SERVICE_ACCOUNT

次のように置き換えます。

IMAGE_URL: コンテナイメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式は REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。
SERVICE_ACCOUNT は、新しい ID に関連付けられたサービスアカウントに置き換えます。この値は、サービスアカウントのメールアドレス（example@myservice.iam.gserviceaccount.com など）です。

YAML

既存のサービス構成をダウンロードして表示するには、gcloud run services describe --format export コマンドを使用します。読みやすく整えられた結果が YAML 形式で出力されます。次に、下記の手順でフィールドを変更し、gcloud run services replace コマンドを使用して変更後の YAML ファイルをアップロードします。必ず説明されているとおりにフィールドを変更してください。

次のコマンドで、構成を表示してダウンロードします。
```
gcloud run services describe SERVICE --format export > service.yaml
```
serviceAccountName: 属性を更新します。
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      serviceAccountName: SERVICE_ACCOUNT
```
次のように置き換えます。
- SERVICE は、Cloud Run サービスの名前に置き換えます。
- SERVICE_ACCOUNT は、新しい ID に関連付けられたサービスアカウントに置き換えます。この値は、サービスアカウントのメールアドレス（example@myproject.iam.gserviceaccount.com など）です。
次のコマンドを使用して、サービスを新しい構成に置き換えます。
```
gcloud run services replace service.yaml
```

Terraform

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

サービスアカウントを作成するには、次のリソースを既存の main.tf ファイルに追加します。

resource "google_service_account" "cloudrun_service_identity" {
  account_id = "my-service-account"
}

Cloud Run サービスを作成または更新し、サービスアカウントを追加します。

resource "google_cloud_run_v2_service" "default" {
  name     = "cloud-run-srv"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    service_account = google_service_account.cloudrun_service_identity.email
  }
}

他のプロジェクトでのサービスアカウントの使用

Cloud Run サービスとは異なる Google Cloud プロジェクトにあるユーザー管理サービスアカウントを使用することもできます。サービスアカウントと Cloud Run サービスが異なるプロジェクトにある場合:

このサービスアカウントを含むプロジェクトでは、組織ポリシー iam.disableCrossProjectServiceAccountUsage をフォルダレベルで false/unenforced に設定するか、プロジェクトレベルの設定から継承する必要があります。デフォルトは true です。
このサービスアカウントには、デプロイプロジェクトのサービスエージェント用に roles/iam.serviceAccountTokenCreator のロール・メンバーシップが必要です。
```
service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com
```
ここで、PROJECT_NUMBER はプロジェクトのプロジェクト番号です。
サービスアカウントには、デプロイオペレーションを実行する ID（ユーザーまたは自動）用に roles/iam.serviceAccountUser のロールメンバーシップが必要です。

ロール・メンバーシップをサービスアカウントリソースに直接適用することも、リソース階層の上位レベルから継承することもできます。

ユーザーが管理するサービスアカウントで Cloud Run を操作するために必要な権限

Cloud Run サービスが Google Cloud の他の部分にアクセスしない場合は、そのサービスアカウントにロールや権限を付与する必要はありません。

Google Cloud コンソールから新しいサービスアカウントを作成する場合は、オプションの「このサービスアカウントにプロジェクトへのアクセス権を付与する」追加の手順が必要です。たとえば、ある Cloud Run サービスから別のプライベート Cloud Run サービスを呼び出す場合や、Cloud SQL データベースにアクセスする場合は、どちらにも特定の IAM ロールが必要です。詳細については、アクセスの管理に関するドキュメントをご覧ください。

メタデータサーバーを使用した ID トークンとアクセストークンの取得

Cloud Run サービスのコードが Google Cloud クライアントライブラリを使用している場合、ライブラリはサービスのランタイムサービスアカウントを使用してコードのリクエストを認証するために、アクセストークンを自動的に取得します。

独自のカスタムコードを使用している場合は、メタデータサーバーを使用して、アクセストークンと ID トークンを手動で取得できます。メタデータサーバーは Google Cloud で動作しているワークロードでのみ使用できるため、ローカルマシンから直接このサーバーにクエリを実行することはできません。

メタデータサーバーで取得できるトークンには次の 2 種類があります。

OAuth 2.0 アクセストークン。ほとんどの Google API の呼び出しに使用されます。
ID トークン。他の Cloud Run サービスや Cloud Functions の呼び出し、ID トークンを検証するサービスの呼び出しに使用されます。

トークンを取得するには、次のいずれかのオプションを選択します。

アクセストークン

たとえば、Pub/Sub トピックを作成する場合は、projects.topics.create メソッドを使用します。

アクセストークンを取得するには、Compute Metadata Server を使用します。
```
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
    --header "Metadata-Flavor: Google"
```
このエンドポイントは、access_token 属性を含む JSON レスポンスを返します。
HTTP/プロトコルリクエストで、Authorization ヘッダー内のアクセストークンによりリクエストの認証を受ける必要があります。
```
PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
Authorization: Bearer ACCESS_TOKEN
```
ここで
- PROJECT_ID はプロジェクト ID です。
- TOPIC_ID はトピック ID です。
- ACCESS_TOKEN は、前の手順で取得したアクセストークンです。
レスポンス:
```
{
    "name": "projects/PROJECT_ID/topics/TOPIC_ID"
}
```

ID トークン

特定のユーザーの ID トークンを取得するには、Compute Metadata Server を使用します。

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
    --header "Metadata-Flavor: Google"

ここで、AUDIENCE は、リクエストされた JWT オーディエンスです。

Cloud Run サービスの場合、オーディエンスは、呼び出すサービスの URL かカスタムオーディエンス（サービス用に構成されたカスタムドメインなど）である必要があります。

https://service.domain.com

他のリソースでは、IAP で保護されたリソースの OAuth クライアント ID の場合もあります。

1234567890.apps.googleusercontent.com

専用のサービスアカウントを作成するための推奨事項を取得する

Recommender サービスは、必要最小限の権限セットで専用のサービスアカウントを作成するための推奨事項を自動的に提供します。

次のステップ

サービスへのアクセスを管理する方法またはデベロッパー、サービス、エンドユーザーの認証を安全に行う方法を学習する。

セキュリティリスクを最小限に抑えるためにサービス ID を使用するアプリケーションのエンドツーエンドのチュートリアルについては、Cloud Run サービスの保護に関するチュートリアルをご覧ください。

サービス ID

デフォルトのサービス アカウントについて

サービスごとの ID の使用

ユーザーが管理するサービス アカウントを割り当てるために必要な権限

ユーザーが管理するサービス アカウントで新しいサービスをデプロイする

コンソール

gcloud

YAML

Terraform

他のプロジェクトでのサービス アカウントの使用

ユーザーが管理するサービス アカウントで Cloud Run を操作するために必要な権限

メタデータ サーバーを使用した ID トークンとアクセス トークンの取得

アクセス トークン

ID トークン

専用のサービス アカウントを作成するための推奨事項を取得する

次のステップ

デフォルトのサービスアカウントについて

ユーザーが管理するサービスアカウントを割り当てるために必要な権限

ユーザーが管理するサービスアカウントで新しいサービスをデプロイする

他のプロジェクトでのサービスアカウントの使用

ユーザーが管理するサービスアカウントで Cloud Run を操作するために必要な権限

メタデータサーバーを使用した ID トークンとアクセストークンの取得

アクセストークン

専用のサービスアカウントを作成するための推奨事項を取得する