一部の Google Cloud リソースでは、リソースがデフォルトの ID として使用するユーザー管理のサービス アカウントを指定できます。このプロセスは、サービス アカウントをリソースに「接続する」、またはサービス アカウントとリソースを「関連付ける」といいます。
リソースは、他の Google Cloud サービスやリソースにアクセスする必要がある場合、接続されたサービス アカウントを ID として使用します。たとえば、サービス アカウントを Compute Engine インスタンスに接続し、そのインスタンス上のアプリケーションがクライアント ライブラリを使用して Google Cloud APIs を呼び出す場合、それらのアプリケーションは自動的に、接続されたサービス アカウントとして認証されます。
このページでは、サービス アカウントを構成して、リソースと接続できるようにする方法について説明します。
始める前に
Enable the IAM and Resource Manager APIs.
IAM のサービス アカウントの仕組みを理解しておく必要があります。
サービス アカウントをリソースに接続する
ほとんどの場合、リソースの作成時にリソース アカウントをサービス アカウントに関連付ける必要があります。リソースの作成後に、リソースに関連付けられているサービス アカウントを変更することはできません。Compute Engine インスタンスは例外です。必要に応じて、インスタンスに接続するサービス アカウントを変更できます。
サービス アカウントは、リソースに接続する前に構成する必要があります。このプロセスは、サービス アカウントとリソースが同じプロジェクト内にあるか、または異なるプロジェクトにあるかによって異なります。サービス アカウントの構成後、リソースを作成してサービス アカウントを接続できます。
同じプロジェクト内のリソースを構成する
同じプロジェクト内の別のリソースにサービス アカウントを接続する前に、他のプリンシパルにロールを付与する場合と同様に、サービス アカウントにロールを付与して、適切なリソースにアクセスできるようにします。
異なるプロジェクトのリソースを構成する
場合によっては、別のプロジェクトに配置されているリソースにサービス アカウントを接続する必要が生じる可能性があります。たとえば、1 つのプロジェクト内にすべてのサービス アカウントを作成する場合には、それらのアカウントの 1 つを別のプロジェクトの新しいリソースに接続する必要が生じる可能性があります。
サービス アカウントを別のプロジェクトのリソースに接続する前に、次のことを実施します。
- サービス アカウントが存在するプロジェクトで、このページの手順に沿ってサービス アカウントをプロジェクト間で接続できるようにします。
- リソースを作成するプロジェクトを特定します。
サービス アカウントを接続するリソースのタイプと、そのタイプのリソースを所有するサービスを特定します。
たとえば、Pub/Sub サブスクリプションを作成する場合、Pub/Sub はリソースを所有するサービスです。
そのサービスを提供するサービス エージェントのメールアドレスを検索します。
サービスによって、使用するサービス エージェントが異なります。詳細については、サービス エージェントをご覧ください。
サービス エージェントにサービス アカウント トークン作成者のロール(
roles/iam.serviceAccountTokenCreator
)を付与します。コンソール
Google Cloud コンソールで、[サービス アカウント] ページに移動します。
リソースに接続するサービス アカウントを所有するプロジェクトを選択します。
リソースに接続するサービス アカウントのメールアドレスをクリックします。
[権限] タブに移動して、[このサービス アカウントにアクセスできるプリンシパル] セクションを探します。
[
アクセス権を付与] をクリックし、サービス エージェントのメールアドレスを入力します。[ロールを選択] をクリックし、「
Service Account Token Creator
」と入力してロールをクリックします。[保存] をクリックして、変更を保存します。
省略可: 別のサービス エージェントにロールを付与する必要がある場合は、上記の手順を繰り返します。
gcloud
gcloud iam service-accounts add-iam-policy-binding
コマンドを実行します。gcloud iam service-accounts add-iam-policy-binding \ SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \ --member=serviceAccount:SERVICE_AGENT_EMAIL \ --role=roles/iam.serviceAccountTokenCreator
次の値を置き換えます。
SERVICE_ACCOUNT_NAME
: リソースに接続するユーザー管理のサービス アカウントの名前。PROJECT_ID
: ユーザー管理のサービス アカウントが存在するプロジェクト ID。SERVICE_AGENT_EMAIL
: サービス エージェントのメールアドレス。
このコマンドでは、ユーザー管理のサービス アカウントの更新済みの許可ポリシーが出力されます。
省略可: 別のサービス エージェントにロールを付与する必要がある場合は、コマンドを再度実行します。
REST
このロールを付与するには、読み取り - 変更 - 書き込みパターンを使用して、ユーザー管理のサービス アカウントの許可ポリシーを更新します。
まず、ユーザー管理のサービス アカウントの許可ポリシーを読み取ります。
projects.serviceAccounts.getIamPolicy
メソッドは、サービス アカウントの許可ポリシーを返します。リクエストのデータを使用する前に、次のように置き換えます。
PROJECT_ID
: Google Cloud プロジェクト ID。プロジェクト ID は英数字からなる文字列です(例:my-project
)。-
USER_SA_NAME
: リソースにバインドするユーザー管理のサービス アカウントの名前。
HTTP メソッドと URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy
リクエストの本文(JSON):
{ "requestedPolicyVersion": 3 }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{ "version": 1, "etag": "BwWl3KCTUMY=", "bindings": [ { "role": "roles/iam.serviceAccountUser", "members": [ "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com" ] } ] }
次に、許可ポリシーを変更して、サービス エージェントにサービス アカウント トークン作成者のロールを付与します。
{ "version": 1, "etag": "BwWl3KCTUMY=", "bindings": [ { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SERVICE_AGENT_EMAIL" ] }, { "role": "roles/iam.serviceAccountUser", "members": [ "serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com" ] } ] }
次のように置き換えます。
SERVICE_AGENT_EMAIL
: サービス エージェントのメールアドレス。SERVICE_ACCOUNT_NAME
: ユーザー管理のサービス アカウントの名前。PROJECT_ID
: ユーザー管理のサービス アカウントが存在するプロジェクト ID。
最後に、更新された許可ポリシーを作成します。
projects.serviceAccounts.setIamPolicy
メソッドは、サービス アカウントの許可ポリシーを更新します。リクエストのデータを使用する前に、次のように置き換えます。
PROJECT_ID
: Google Cloud プロジェクト ID。プロジェクト ID は英数字からなる文字列です(例:my-project
)。-
USER_SERVICE_ACCOUNT_NAME
: リソースにバインドするユーザー管理のサービス アカウントの名前。 -
SERVICE_AGENT_EMAIL
: ユーザー管理のサービス アカウントのアクセス トークンを作成するサービス エージェントのメールアドレス。
HTTP メソッドと URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy
リクエストの本文(JSON):
{ "policy": { "version": 1, "etag": "BwWl3KCTUMY=", "bindings": [ { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SERVICE_AGENT_EMAIL" ] }, { "role": "roles/iam.serviceAccountUser", "members": [ "serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com" ] } ] } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{ "version": 1, "etag": "BwWo331TkHE=", "bindings": [ { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SERVICE_AGENT_EMAIL" ] }, { "role": "roles/iam.serviceAccountUser", "members": [ "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com" ] } ] }
サービス アカウントを新しいリソースに接続する
ユーザー管理のサービス アカウントの構成後、新しいリソースを作成してサービス アカウントを接続できます。新しいリソースは、適切なプロジェクトで作成するようにしてください。
作成するリソースの種類に応じた手順をご覧ください。
リソースの作成時にサービス アカウントを接続する | |
---|---|
AI Platform の予測 | モデル バージョン |
AI Platform Training | ジョブ |
App Engine スタンダード環境 | アプリのバージョン |
App Engine フレキシブル環境 | アプリのバージョン |
Cloud Composer | 環境 |
Cloud Functions | Cloud Functions の関数 |
Cloud Life Sciences | パイプライン |
Cloud Run | サービス |
Cloud Scheduler | ジョブ |
Cloud Source Repositories |
|
Compute Engine | |
Dataflow | ジョブ |
Datalab | インスタンス |
Dataproc | クラスタ |
Eventarc | トリガー |
Google Kubernetes Engine | |
ノートブック | ノートブック インスタンス |
Pub/Sub | 登録 |
Vertex AI | |
Workflows | Workflows |
リソースを作成してそのリソースにサービス アカウントを関連付けると、適切なリソースにアクセスできるようにサービス アカウントにロールを付与できます。このプロセスは、他のプリンシパルにロールを付与する場合と同じです。
ロールを付与する方法については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。
サービス アカウントを別のプロジェクトのリソースに接続する
デフォルトでは、あるプロジェクトでサービス アカウントを作成したとき、そのアカウントを別のプロジェクトのリソースに接続することはできません。すべてのサービス アカウントを 1 つのプロジェクトで保持する場合は、そのプロジェクトの組織のポリシーを更新する必要があります。
プロジェクト間でのサービス アカウントの接続を有効にする
あるプロジェクトのサービス アカウントを別のプロジェクトのリソースに接続できるようにするには、サービス アカウントが配置されているプロジェクトの組織のポリシーで、次のブール型制約を確認します。
iam.disableCrossProjectServiceAccountUsage
ブール型制約はプロジェクトに適用しないようにしてください。このブール型制約は、サービス アカウントを別のプロジェクトのリソースに接続できるかどうかを制御します。この制約はデフォルトで適用されます。
この制約が適用されていない場合は、プロジェクトの削除を防止するプロジェクト リーエンが IAM によって追加されます。このリーエンは元の
iam.googleapis.com/cross-project-service-accounts
を持ちます。このリーエンは削除しないことを強くおすすめします。推奨:
iam.restrictCrossProjectServiceAccountLienRemoval
ブール型制約がプロジェクトに適用されていることを確認してください。このブール型制約は、組織レベルで
resourcemanager.projects.updateLiens
権限を付与されている場合にのみ、プリンシパルがプロジェクト リーエンを削除できるようにします。この制約が適用されていない場合、プリンシパルはプロジェクト レベルでこの権限があればプロジェクト リーエンを削除できます。
組織のポリシーのブール型制約を確認、変更する方法については、組織のポリシーの作成と管理をご覧ください。
プロジェクト間でのサービス アカウントの接続を無効にする
以前にプロジェクト間のサービス アカウントの接続を有効にした場合、特に本番環境では、この機能を無効しないことを強くおすすめします。
具体的には、サービス アカウントが存在するプロジェクトで次のような変更を行うことは推奨されません。
iam.disableCrossProjectServiceAccountUsage
ブール型制約を適用するようにプロジェクトの組織のポリシーを更新することは控える。iam.restrictCrossProjectServiceAccountLienRemoval
ブール型制約を適用しないようにプロジェクトの組織ポリシーを更新することは控える。- 元の
iam.googleapis.com/cross-project-service-accounts
があるプロジェクト リーエンの削除は控える。こうすることでプロジェクトの削除を防止できます。 - プロジェクトの削除は控える。
この機能を無効にすることで発生するリスクをとる場合、そのリスクを軽減するには、プロジェクト間で使用しているサービス アカウントを無効にし、問題が生じないかどうか、Google Cloud 環境をモニタリングします。問題が見つかった場合は、サービス アカウントを再度有効にできます。問題が生じない場合は、別のプロジェクトのサービス アカウントに依存する Google Cloud リソースが存在しないことが考えられます。
次のステップ
- サービス アカウントを Compute Engine インスタンスに接続する方法を確認する。
- サービス アカウント保護のベスト プラクティスを確認して適用する。
- IAM の監査ロギングの詳細を確認する。