サービス ID

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

サービス アカウントの指定がない場合、Cloud Run はすべての Google Cloud API に対して幅広い権限を持つデフォルトのサービス アカウントにリビジョンをリンクします。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 CLIGoogle Cloud クライアント ライブラリは、Google Cloud での実行を自動的に検出し、現在の Cloud Run リビジョンのランタイム サービス アカウントを使用します。つまり、コードが gcloud CLI または公式の Google Cloud クライアント ライブラリを使用する場合、Cloud Run サービスのランタイム サービス アカウントとして自動的に検出され、認証されます。この方法はアプリケーションのデフォルト認証情報と呼ばれ、複数の環境にコードを移植できます。

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

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

ユーザー管理サービス アカウントを使用して 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 "user@example.com" \
    --role "roles/iam.serviceAccountUser"

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

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

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

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

コンソール

  1. Cloud Run に移動します

  2. デプロイ先の新しいサービスを構成する場合は、[サービスの作成] をクリックします。既存のサービスを構成する場合は、サービスをクリックし、[新しいリビジョンの編集とデプロイ] をクリックします。

  3. 新しいサービスを構成する場合は、最初のサービス設定のページに入力してから、[コンテナ、接続、セキュリティ] をクリックしてサービス構成ページを開きます。

  4. [セキュリティ] タブをクリックします。

    画像

  5. [サービス アカウント] プルダウンをクリックして、目的のサービス アカウントを選択します。

  6. [作成] または [デプロイ] をクリックします。

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 など)に置き換えます。
  • SERVICE_ACCOUNT は、新しい ID に関連付けられたサービス アカウントに置き換えます。この値は、サービス アカウントのメールアドレス(example@myservice.iam.gserviceaccount.com など)です。

YAML

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

  1. 次のコマンドで、構成を表示してダウンロードします。

    gcloud run services describe SERVICE --format export > service.yaml
  2. 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 など)です。
  3. 次のコマンドを使用して、サービスを新しい構成に置き換えます。

    gcloud run services replace service.yaml

Terraform

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

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

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

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

  template {
    spec {
      containers {
        image = "gcr.io/cloudrun/hello"
      }
      service_account_name = google_service_account.cloudrun_service_identity.email
    }
  }

  traffic {
    percent         = 100
    latest_revision = true
  }
}

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

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 で動作しているワークロードでのみ使用できるため、ローカルマシンから直接このサーバーにクエリを実行することはできません。

アクセス トークン

ほとんどの場合、Google API を呼び出すときに OAuth 2.0 アクセス トークンを使用します。アクセス トークンを生成するには:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
    --header "Metadata-Flavor: Google"

デフォルトでは、アクセス トークンに cloud-platform スコープが設定されています。IAM でアクセスが許可されていれば、すべての Google Cloud Platform API にアクセスできます。他の Google または Google Cloud APIs にアクセスするには、適切なスコープのアクセス トークンを取得する必要があります。別のスコープを指定するには:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token?scopes=SCOPES" \
    --header "Metadata-Flavor: Google"

ここで SCOPES は、リクエストされた OAuth スコープのカンマ区切りのリストです。例:

https://www.googleapis.com/auth/drive,https://www.googleapis.com/auth/spreadsheets

Google OAuth スコープの完全なリストを調べて、必要なスコープを探してください。詳しくは、アクセス トークンの取得もご覧ください。

ID トークン

ID トークンは、他の Cloud Run サービスを呼び出すときや、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 サービスの保護に関するチュートリアルをご覧ください。