サービス ID

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

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

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

サービスごとの ID の使用

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

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

ユーザー管理サービス アカウントに必要な権限

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

この権限は、Cloud Console、API(YAML)または gcloud ツールを使用して付与できます。手順は次のとおりです。

gcloud iam service-accounts add-iam-policy-binding "SERVICE_ACCOUNT_EMAIL" \
    --member "user@example.com" \
    --role "roles/iam.serviceAccountUser"

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

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

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

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

Console

  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

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

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 のロール メンバーシップが必要です。

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

ID とアクセス トークンの取得

Cloud Run サービスのコードで Google Cloud クライアント ライブラリを使用している場合は、ID またはアクセス トークンを取得する必要はありません。これらのクライアント ライブラリは、Cloud Run サービスのランタイム サービス アカウントを使用して自動的に検出と認証を行います。

Cloud Run サービスで実行されるカスタムコードでは、メタデータ サーバーを使用して 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 サービスの保護に関するチュートリアルをご覧ください。