サービス アカウントの権限借用の管理

このページでは、プリンシパルとリソースに Identity and Access Management(IAM)サービス アカウントの権限借用を許可する方法について説明します。また、特定の IAM サービス アカウントの権限を借用できるプリンシパルを確認する方法についても説明します。

始める前に

プリンシパルにサービス アカウントの権限借用を許可する

プリンシパルにサービス アカウントの権限借用を許可する事前定義ロールがいくつかあります。

  • サービス アカウント ユーザー(roles/iam.serviceAccountUser: このロールには iam.serviceAccounts.actAs 権限が含まれており、プリンシパルは、サービス アカウントがアクセスできるすべてのリソースに間接的にアクセスできます。たとえば、プリンシパルにサービス アカウントのサービス アカウント ユーザーロールが付与され、サービス アカウントにプロジェクトの Cloud SQL 管理者ロール(roles/cloudsql.admin)が付与されている場合、このプリンシパルはサービス アカウントして Cloud SQL インスタンスを作成できます。

    また、このページで説明するように、プリンシパルは、このロールでもサービス アカウントをリソースに適用できます。

    このロールでは、プリンシパルがサービス アカウントの有効期間が短い認証情報を作成することや、Google Cloud CLI の --impersonate-service-account フラグを使用することはできません。こうしたタスクを完了するには、サービス アカウント トークン作成者ロールも必要です。

  • サービス アカウント トークン作成者(roles/iam.serviceAccountTokenCreator: このロールにより、プリンシパルがサービス アカウントの権限を借用でき、次のことを行います。

    • Google API での認証に使用できる OAuth 2.0 アクセス トークンを作成する
    • OpenID Connect(OIDC)ID トークンを作成する
    • 認証に使用できるように JSON ウェブトークン(JWT)とバイナリ blob に署名する

    詳細については、有効期間が短いサービス アカウント認証情報の作成をご覧ください。

    このロールの権限は次のとおりです。

    • iam.serviceAccounts.getAccessToken: OAuth 2.0 アクセス トークンの作成
    • iam.serviceAccounts.getOpenIdToken: OpenID Connect(OICD)ID トークンの作成
    • iam.serviceAccounts.implicitDelegation: サービス アカウントによる委任チェーンでのトークンの取得
    • iam.serviceAccounts.signBlob: バイナリ blob への署名
    • iam.serviceAccounts.signJwt: JWT への署名
  • Workload Identity ユーザー(roles/iam.workloadIdentityUser: このロールにより、プリンシパルは GKE ワークロードのサービス アカウントの権限を借用できます。

    このロールの権限は次のとおりです。

    • iam.serviceAccounts.getAccessToken: OAuth 2.0 アクセス トークンの作成
    • iam.serviceAccounts.getOpenIdToken: OpenID Connect(OICD)ID トークンの作成

また、別の事前定義ロールや、サービス アカウントの権限を借用するカスタムロールを付与することもできます。

ここでは、これらのロールをプロジェクト、フォルダ、組織に付与する方法と、個々のサービス アカウントに付与する方法について説明します。付与するアクセス権の量に応じてレベルを選択します。

プリンシパルに複数のサービス アカウントの権限借用を許可する

プロジェクト、フォルダまたは組織に作成されたすべてのサービス アカウントの権限借用をプリンシパルに許可するには、プロジェクト、フォルダまたは組織にロールを付与します。

コンソール

  1. Google Cloud コンソールの [IAM] ページに移動します。

    [IAM] ページに移動

  2. ページの上部にあるプロジェクト セレクタから、ロールを付与するプロジェクト、フォルダ、または組織を選択します。

  3. [追加] をクリックします。

  4. プリンシパルのメールアドレスを入力します。

  5. プリンシパルに許可するサービス アカウントのロールを選択します。サービス アカウントの権限借用に使用するロールをご覧ください。

  6. [保存] をクリックします。

gcloud CLI

サービス アカウントの権限借用に使用するロールをプリンシパルに付与するには、プロジェクト、フォルダまたは組織の許可ポリシーを変更します。

  1. リソースの許可ポリシーを読み取ります。

    gcloud resource get-iam-policy resource-id \
        --format=json > policy.json
    

    次の値を置き換えます。

    • resource: 許可ポリシーを設定するリソースのタイプ。この値は、projectsresource-manager foldersorganizations のいずれかにする必要があります。
    • resource-id: 許可ポリシーを設定するリソースの ID。

    このコマンドは、リソースの許可ポリシーを policy.json ファイルに保存します。

    リソースに許可ポリシーがすでに設定されている場合、policy.json ファイルは次のようになります。

    {
      "bindings": [
        {
          "members": [
            "user:hollis@example.com"
          ],
          "role": "roles/owner"
        }
      ],
      "etag": "BwUqLaVeua8=",
      "version": 1
    }
    

    リソースに許可ポリシーがない場合、policy.json ファイルにはデフォルトの etag のみが含まれます。

    既存の許可ポリシーがない場合は、以降の手順で JSON をテンプレートとして使用し、許可ポリシーを手動で作成します。

  2. 適切なロールがプリンシパルに付与されるように許可ポリシーを変更します。次のいずれかの方法でロールを付与します。

    • ロール バインディングが存在しない場合は、付与するロールとプリンシパルを表す bindings 配列にオブジェクトを追加します。
    • ロール バインディングがすでに存在する場合は、既存のプリンシパルのリストに新しいプリンシパルを追加します。許可ポリシーに条件付きロール バインディングが含まれている場合は、プリンシパルを追加する前に、バインディングに適切な条件があることも確認します。

    bindings 配列が存在しない場合は、配列を作成できます。

    サービス アカウント ユーザーロール(roles/iam.serviceAccountUser)を robin@example.com に付与するには、上記の例を次のように変更します。

    {
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "user:robin@example.com"
          ]
        },
        {
          "role": "roles/owner",
          "members": [
            "user:hollis@example.com"
          ]
        }
      ],
      "etag": "BwUqLaVeua8=",
      "version": 1
    }
    
  3. 更新された許可ポリシーを書き込みます。

    gcloud resource set-iam-policy resource-id \
        policy-file
    

    次の値を置き換えます。

    • resource: 許可ポリシーを設定するリソースのタイプ。この値は、projectsresource-manager foldersorganizations のいずれかにする必要があります。
    • resource-id: 許可ポリシーを設定するリソースの ID。
    • policy-file: 更新された許可ポリシーを含むファイルのパス。

    このコマンドは、更新された etag 値を含む更新後の許可ポリシーを出力します。

REST

Resource Manager REST API を使用してロールを付与するには、プロジェクト、フォルダ、または組織の現在の許可ポリシーを読み取り、目的のロールが付与されるように許可ポリシーを変更し、更新後の許可ポリシーを書き込む必要があります。

リソースの許可ポリシーを読み取ります。

Resource Manager API の getIamPolicy メソッドは、プロジェクト、フォルダ、または組織の許可ポリシーを取得します。

リクエストのデータを使用する前に、次のように置き換えます。

  • API_VERSION: 使用する API のバージョン。プロジェクトと組織の場合は、v1 を使用します。フォルダの場合は、v2 を使用します。
  • RESOURCE_TYPE: ポリシーを管理するリソースタイプ。値 projectsfolders、または organizations を使用します。
  • RESOURCE_ID: Google Cloud プロジェクト、組織、またはフォルダ ID。プロジェクト ID は英数字からなる文字列です(例: my-project)。フォルダ ID と組織 ID は数値です(例: 123456789012)。
  • POLICY_VERSION: 返されるポリシー バージョン。リクエストでは、最新のポリシー バージョン(ポリシー バージョン 3)を指定する必要があります。詳細については、ポリシーの取得時にポリシー バージョンを指定するをご覧ください。

HTTP メソッドと URL:

POST https://cloudresourcemanager.googleapis.com/API_VERSION/RESOURCE_TYPE/RESOURCE_ID:getIamPolicy

JSON 本文のリクエスト:

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

リクエストを送信するには、次のいずれかのオプションを展開します。

レスポンスには、リソースの許可ポリシーが含まれます。次に例を示します。

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/owner",
      "members": [
        "user:owner@example.com"
      ]
    }
  ]
}

既存の許可ポリシーがない場合、レスポンスにはデフォルトの etag のみが含まれます。このレスポンスが返された場合は、version フィールドを追加して 3 に設定し、bindings フィールドを空の配列に設定します。

適切なロールがプリンシパルに付与されるように許可ポリシーを変更します。

次のいずれかの方法でロールを付与します。

  • ロール バインディングが存在しない場合は、付与するロールとプリンシパルを表す bindings 配列にオブジェクトを追加します。
  • ロール バインディングがすでに存在する場合は、既存のプリンシパルのリストに新しいプリンシパルを追加します。

:

サービス アカウント ユーザーロール(roles/iam.serviceAccountUser)を robin@example.com に付与するには、上記の例を次のように変更します。

{
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/owner",
      "members": [
        "user:owner@example.com"
      ]
    }
  ]
}

更新された許可ポリシーを書き込みます。

Resource Manager API の setIamPolicy メソッドを使用して、プロジェクト、フォルダまたは組織の新しい許可ポリシーとしてリクエストのポリシーを設定します。

リクエストのデータを使用する前に、次のように置き換えます。

  • API_VERSION: 使用する API のバージョン。プロジェクトと組織の場合は、v1 を使用します。フォルダの場合は、v2 を使用します。
  • RESOURCE_TYPE: ポリシーを管理するリソースタイプ。値 projectsfolders、または organizations を使用します。
  • RESOURCE_ID: Google Cloud プロジェクト、組織、またはフォルダ ID。プロジェクト ID は英数字からなる文字列です(例: my-project)。フォルダ ID と組織 ID は数値です(例: 123456789012)。
  • POLICY: 設定するポリシーの JSON 表現。ポリシーの形式については、ポリシー リファレンスをご覧ください。

    たとえば、前の手順で示した許可ポリシーを設定するには、POLICY を次のコードに置き換えます。

    {
      "version": 1,
      "etag": "BwUqLaVeua8=",
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "user:robin@example.com"
          ]
        },
        {
          "role": "roles/owner",
          "members": [
            "user:owner@example.com"
          ]
        }
      ]
    }
    

HTTP メソッドと URL:

POST https://cloudresourcemanager.googleapis.com/API_VERSION/RESOURCE_TYPE/RESOURCE_ID:setIamPolicy

JSON 本文のリクエスト:

{
  "policy": POLICY
}

リクエストを送信するには、次のいずれかのオプションを展開します。

レスポンスには、更新された許可ポリシーが含まれます。

プリンシパルに 1 つのサービス アカウントの権限の使用を許可する

プリンシパルに 1 つのサービス アカウントの権限の使用を許可するには、サービス アカウントにロールを付与します。

コンソール

  1. Google Cloud コンソールで、[サービス アカウント] ページに移動します。

    [サービス アカウント] ページに移動

  2. プロジェクトを選択します。

  3. プリンシパルに権限借用を許可するサービス アカウントのメールアドレスをクリックします。

  4. [権限] タブをクリックします。

  5. [このサービス アカウントにアクセスできるプリンシパル] で、[アクセスを許可] をクリックします。

  6. プリンシパルのメールアドレスを入力します。

  7. サービス アカウントの権限借用を許可するためにプリンシパルに付与するロールを選択します。サービス アカウントの権限借用に使用するロールをご覧ください。

  8. プリンシパルにロールを適用するには、[保存] をクリックします。

複数のサービス アカウントにロールを付与するには、それぞれのサービス アカウントに同じ手順を繰り返します。

gcloud CLI

サービス アカウントの権限借用を許可するためにプリンシパルにロールを付与するには、サービス アカウントの許可ポリシーを変更します。

  1. service-accounts get-iam-policy コマンドを使用して、現在の許可ポリシーを読み取ります。

    gcloud iam service-accounts get-iam-policy sa-id \
        --format=json > policy.json
    

    次の値を置き換えます。

    • sa-id: サービス アカウントの ID。サービス アカウントのメールアドレス(sa-name@project-id.iam.gserviceaccount.com の形式)か、サービス アカウントの一意の数値 ID のいずれかを指定します。

    このコマンドは、サービス アカウントの許可ポリシーを policy.json ファイルに保存します。

    サービス アカウントに許可ポリシーがすでに設定されている場合、policy.json ファイルは次のようになります。

    {
      "bindings": [
        {
          "members": [
            "user:hollis@example.com"
          ],
          "role": "roles/iam.serviceAccountAdmin"
        }
      ],
      "etag": "BwUqLaVeua8=",
      "version": 1
    }
    

    サービス アカウントに許可ポリシーが設定されていない場合、policy.json ファイルにはデフォルトの etag のみが含まれます。

    既存の許可ポリシーがない場合は、以降の手順で JSON をテンプレートとして使用し、許可ポリシーを手動で作成します。

  2. テキスト エディタで、policy.json ファイルを開き、プリンシパルに適切なロールが付与されるようにバインディング配列を変更します。次のいずれかの方法でロールを付与します。

    • ロール バインディングが存在しない場合は、付与するロールとプリンシパルを定義する bindings 配列に新しいオブジェクトを追加します。
    • ロール バインディングがすでに存在する場合は、既存のプリンシパルのリストに新しいプリンシパルを追加します。許可ポリシーに条件付きロール バインディングが含まれている場合は、プリンシパルを追加する前に、バインディングに適切な条件があることも確認します。

    bindings 配列が存在しない場合は、配列を作成できます。

    サービス アカウント ユーザーロール(roles/iam.serviceAccountUser)を robin@example.com に付与するには、上記の例を次のように変更します。

    {
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "user:robin@example.com"
          ]
        },
        {
          "role": "roles/iam.serviceAccountAdmin",
          "members": [
            "user:hollis@example.com"
          ]
        }
      ],
      "etag": "BwUqLaVeua8=",
      "version": 1
    }
    
  3. service-accounts set-iam-policy コマンドを使用して、更新された許可ポリシーを書き込みます。

    gcloud iam service-accounts set-iam-policy sa-id \
        policy-file
    

    次の値を置き換えます。

    • sa-id: サービス アカウントの ID。サービス アカウントのメールアドレス(sa-name@project-id.iam.gserviceaccount.com の形式)か、サービス アカウントの一意の数値 ID のいずれかを指定します。
    • policy-file: 更新された許可ポリシーを含むファイルのパス。

    このコマンドは、更新された etag 値を含む更新後の許可ポリシーを出力します。

REST

IAM REST API を使用してロールを付与するには、サービス アカウントの現在の許可ポリシーを読み取り、目的のロールが付与されるように変更し、更新後の許可ポリシーを書き込む必要があります。

サービス アカウントの許可ポリシーを読み取ります。

serviceAccounts.getIamPolicy メソッドで、サービス アカウントの許可ポリシーを取得します。

リクエストのデータを使用する前に、次のように置き換えます。

  • PROJECT_ID: Google Cloud プロジェクト ID。プロジェクト ID は英数字からなる文字列です(例: my-project)。
  • SA_ID: サービス アカウントの ID。これは、サービス アカウントのメールアドレス(SA_NAME@PROJECT_ID.iam.gserviceaccount.com の形式)、またはサービス アカウントの一意の数値 ID のいずれかです。

  • POLICY_VERSION: 返されるポリシー バージョン。リクエストでは、最新のポリシー バージョン(ポリシー バージョン 3)を指定する必要があります。詳細については、ポリシーの取得時にポリシー バージョンを指定するをご覧ください。

HTTP メソッドと URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:getIamPolicy

JSON 本文のリクエスト:

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

リクエストを送信するには、次のいずれかのオプションを展開します。

レスポンスには、サービス アカウントの許可ポリシーが含まれます。次に例を示します。

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

既存の許可ポリシーがない場合、レスポンスにはデフォルトの etag のみが含まれます。このレスポンスが返された場合は、version フィールドを追加して 3 に設定し、bindings フィールドを空の配列に設定します。

適切なロールがプリンシパルに付与されるように許可ポリシーを変更します。

テキスト エディタでレスポンスの本文を開き、プリンシパルに適切なロールが付与されるようにバインディング配列を変更します。次のいずれかの方法でロールを付与します。

  • ロール バインディングが存在しない場合は、付与するロールとプリンシパルを定義する bindings 配列に新しいオブジェクトを追加します。
  • ロール バインディングがすでに存在する場合は、既存のプリンシパルのリストに新しいプリンシパルを追加します。

:

サービス アカウント ユーザーロール(roles/iam.serviceAccountUser)を robin@example.com に付与するには、上記の例を次のように変更します。

{
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

更新された許可ポリシーを書き込みます。

serviceAccounts.setIamPolicy メソッドは、サービス アカウントに更新後の許可ポリシーを設定します。

リクエストのデータを使用する前に、次のように置き換えます。

  • PROJECT_ID: Google Cloud プロジェクト ID。プロジェクト ID は英数字からなる文字列です(例: my-project)。
  • SA_ID: サービス アカウントの ID。これは、サービス アカウントのメールアドレス(SA_NAME@PROJECT_ID.iam.gserviceaccount.com の形式)、またはサービス アカウントの一意の数値 ID のいずれかです。

  • POLICY: 設定するポリシーの JSON 表現。ポリシーの形式については、ポリシー リファレンスをご覧ください。

    たとえば、前の手順で示した許可ポリシーを設定するには、policy を次のコードに置き換えます。

    {
      "version": 1,
      "etag": "BwUqLaVeua8=",
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "user:robin@example.com"
          ]
        },
        {
          "role": "roles/serviceAccountAdmin",
          "members": [
            "user:admin@example.com"
          ]
        }
      ]
    }
    

HTTP メソッドと URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:setIamPolicy

JSON 本文のリクエスト:

{
  "policy": POLICY
}

リクエストを送信するには、次のいずれかのオプションを展開します。

レスポンスには、更新された許可ポリシーが含まれます。

サービス アカウントにアクセスできるプリンシパルを一覧表示する

サービス アカウントに付与されたロール、またはプロジェクト、フォルダ、組織に付与されたロールにより、サービス アカウントへのアクセスが許可されているプリンシパルを確認するには、Google Cloud コンソールを使用します。

  1. Google Cloud コンソールで、[サービス アカウント] ページに移動します。

    [サービス アカウント] に移動

  2. プロジェクトを選択します。

  3. プリンシパルに権限借用を許可するサービス アカウントのメールアドレスをクリックします。

  4. [権限] タブをクリックします。[このサービス アカウントにアクセスできるプリンシパル] セクションには、サービス アカウントにアクセスできるプリンシパルが表示されます。

サービス アカウントをリソースに関連付ける

一部の Google Cloud リソースでは、リソースがデフォルトの ID として使用するユーザー管理のサービス アカウントを指定できます。このプロセスは、サービス アカウントをリソースに「接続する」、またはサービス アカウントとリソースを「関連付ける」といいます。

リソースは、他の Google Cloud サービスとリソースにアクセスする必要がある場合、自身に接続されたサービス アカウントの権限を借用します。たとえば、サービス アカウントを Compute Engine インスタンスに接続し、そのインスタンス上のアプリケーションがクライアント ライブラリを使用して Google Cloud APIs を呼び出す場合、それらのアプリケーションは自動的に、接続されたサービス アカウントの権限を借用します。

ほとんどの場合、リソースの作成時にリソース アカウントをサービス アカウントに関連付ける必要があります。リソースの作成後に、リソースに関連付けられているサービス アカウントを変更することはできません。Compute Engine インスタンスは例外です。必要に応じて、インスタンスに接続するサービス アカウントを変更できます。

サービス アカウントは、リソースに接続する前に構成する必要があります。このプロセスは、サービス アカウントとリソースが同じプロジェクト内にあるか、または異なるプロジェクトにあるかによって異なります。サービス アカウントの構成後、リソースを作成してサービス アカウントを接続できます。

同じプロジェクト内のリソースを構成する

同じプロジェクト内の別のリソースにサービス アカウントを接続する前に、他のプリンシパルにロールを付与する場合と同様に、サービス アカウントにロールを付与して、適切なリソースにアクセスできるようにします。

異なるプロジェクトのリソースを構成する

場合によっては、別のプロジェクトに配置されているリソースにサービス アカウントを接続する必要が生じる可能性があります。たとえば、1 つのプロジェクト内にすべてのサービス アカウントを作成する場合には、それらのアカウントの 1 つを別のプロジェクトの新しいリソースに接続する必要が生じる可能性があります。

サービス アカウントを別のプロジェクトのリソースに接続する前に、次のことを実施します。

  1. サービス アカウントが存在するプロジェクトで、このページの手順に沿ってプロジェクト間のサービス アカウントの権限借用を有効にします
  2. リソースを作成するプロジェクトを特定します。
  3. サービス アカウントを接続するリソースのタイプと、そのタイプのリソースを所有するサービスを特定します。

    たとえば、Pub/Sub サブスクリプションを作成する場合、Pub/Sub はリソースを所有するサービスです。

  4. そのサービスを提供するサービス エージェントのメールアドレスを検索します。

    サービスによって、使用するサービス エージェントが異なります。詳細については、サービス エージェントをご覧ください。

  5. サービス エージェントにサービス アカウント トークン作成者のロール(roles/iam.serviceAccountTokenCreator)を付与します。

    コンソール

    1. Google Cloud コンソールで、[サービス アカウント] ページに移動します。

      [サービス アカウント] に移動

    2. リソースに接続するサービス アカウントを所有するプロジェクトを選択します。

    3. リソースに接続するサービス アカウントを見つけて、そのチェックボックスをオンにします。

    4. [権限] タブで、[プリンシパルを追加] をクリックします。

    5. [新しいプリンシパル] フィールドに、サービス エージェントのメールアドレスを入力します。

    6. [ロールを選択] プルダウン リストで「Service Account Token Creator」と入力し、ロールをクリックします。

    7. [保存] をクリックして、変更を保存します。

    8. 省略可: 別のサービス エージェントにロールを付与する必要がある場合は、上記の手順を繰り返します。

    gcloud CLI

    gcloud iam service-accounts add-iam-policy-binding コマンドを実行します。

    gcloud iam service-accounts add-iam-policy-binding \
        user-sa-name@project-id.iam.gserviceaccount.com \
        --member=serviceAccount:service-agent-email \
        --role=roles/iam.serviceAccountTokenCreator
    

    次の値を置き換えます。

    • user-sa-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"
          ]
        }
      ]
    }
    

    次に、許可ポリシーを変更して、サービス エージェントにサービス アカウント トークン作成者のロールを付与します。SERVICE_AGENT_EMAIL は、サービス エージェントのメールアドレスに置き換えます。

    {
      "version": 1,
      "etag": "BwWl3KCTUMY=",
      "bindings": [
        {
          "role": "roles/iam.serviceAccountTokenCreator",
          "members": [
            "serviceAccount:SERVICE_AGENT_EMAIL"
          ]
        },
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"
          ]
        }
      ]
    }
    

    最後に、更新された許可ポリシーを作成します。

    projects.serviceAccounts.setIamPolicy メソッドは、サービス アカウントの許可ポリシーを更新します。

    リクエストのデータを使用する前に、次のように置き換えます。

    • PROJECT_ID: Google Cloud プロジェクト ID。プロジェクト ID は英数字からなる文字列です(例: my-project)。
    • USER_SA_NAME: リソースにバインドするユーザー管理のサービス アカウントの名前。
    • SERVICE_AGENT_EMAIL: ユーザー管理のサービス アカウントのアクセス トークンを作成するサービス エージェントのメールアドレス。

    HTTP メソッドと URL:

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_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:my-service-account@my-project.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 クラスタ
Google Kubernetes Engine
ノートブック ノートブック インスタンス
Pub/Sub 登録
Vertex AI
Workflows Workflows

リソースを作成してそのリソースにサービス アカウントを関連付けると、適切なリソースにアクセスできるようにサービス アカウントにロールを付与できます。このプロセスは、他のプリンシパルにロールを付与する場合と同じです。

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

監査ログの解釈

Cloud Audit Logs を使用すると、Google Cloud リソースに対して「いつ誰がどこで何をしたか」を調べることができます。

有効期間の短い認証情報を使用してサービス アカウントの権限を借用すると、ほとんどの Google Cloud サービスのログエントリには次の ID が表示されます。

  • 有効期間の短い認証情報が権限を借用するサービス アカウント
  • 有効期間の短い認証情報を作成した ID

これらのログエントリを使用して、有効期間が短い認証情報を作成したプリンシパルと、プリンシパルが権限を借用したサービス アカウントを特定できます。

サービス アカウントのなりすましを示す監査ログエントリの例については、サービス アカウントに成り代わって Google Cloud にアクセスするをご覧ください。

プロジェクト間のサービス アカウントの権限借用を有効にする

デフォルトでは、あるプロジェクトでサービス アカウントを作成したとき、そのアカウントを別のプロジェクトのリソースに接続することはできません。すべてのサービス アカウントを 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 リソースが存在しないことが考えられます。

次のステップ