インスタンスのサービスアカウントの作成と有効化

このページでは、仮想マシンインスタンスでサービスアカウントを作成して使用する方法について説明します。サービスアカウントは、他の Google Cloud Platform サービスにアクセスするためにアプリケーションコードで使用できる認証情報を持つ特別なアカウントです。

サービスアカウントの詳細については、サービスアカウントの概要をご覧ください。

始める前に

このガイドのコマンドラインの例を使用する場合、以下を行います。
1. gcloud コマンドラインツールをインストールします。
2. デフォルトのリージョンとゾーンを設定します。
このガイドの API の例を使用する場合は、API アクセスを設定してください。
サービスアカウントの概要を参照してください。

新しいサービスアカウントを作成する

Google Cloud Identity and Access Management（IAM）を使用して、新しいサービスアカウントを作成して設定することができます。アカウントを作成した後で、1 つ以上の IAM の役割をアカウントに付与し、そのサービスアカウントとして走行する仮想マシンインスタンスを承認します。

新しいサービスアカウントを作成するには次の手順に従います。

IAM サービスアカウントのドキュメントの説明に沿って、新しいサービスアカウントを作成します。
サービスアカウントのメールアドレスを取得します。 このサービスアカウントとして走行するインスタンスを設定するためにメールアドレスが必要です。Console でサービスアカウントのメールアドレスを確認します。
1. GCP Console の [サービスアカウント] ページに移動します。
  [サービスアカウント] ページに移動
2. プロンプトが表示されたら、プロジェクトを選択します。
3. 新しいサービスアカウントを探し、サービスアカウントのメールアドレスをメモします。
通常、サービスアカウントのメールアドレスは、次の形式でサービスアカウント ID から取得されます。
```
[SERVICE-ACCOUNT-NAME]@[PROJECT_ID].iam.gserviceaccount.com
```
サービスアカウントに IAM 役割を付与します。役割を付与しないと、サービスアカウントがサービスにアクセスできなくなります。IAM の役割の一覧については、IAM ドキュメントの役割についてをご覧ください。
次に、サービスアカウントとして走行するようにインスタンスを設定します。 手順に従い、サービスアカウントとして走行するようにインスタンスを設定します。

新しいインスタンスをサービスアカウントとして走行するように設定する

新しいサービスアカウントを作成したら、サービスアカウントとして走行する新しい仮想マシンインスタンスを作成できます。既存のインスタンスにサービスアカウントを割り当てたり、サービスアカウントを変更したりする場合には、インスタンスのサービスアカウントとアクセススコープを変更するをご覧ください。

同じサービスアカウントを複数の仮想マシンインスタンスで使用することができますが、1 つの仮想マシンインスタンスに設定できるサービスアカウント ID は 1 つだけです。同じサービスアカウントを複数の仮想マシンインスタンスに割り当てた場合、それ以降そのサービスアカウントに行った変更は、そのサービスアカウントを使用しているすべてのインスタンスに影響します。これには、そのサービスアカウントに付与されている IAM の役割に加えた変更も含まれます。たとえば、役割を削除した場合、そのサービスアカウントを使用しているすべてのインスタンスは、その役割によって付与されている権限を失います。

サービスアカウントとして実行されるように新しいインスタンスを設定するには、Google Cloud Platform Console または gcloud コマンドラインツールを使用します。あるいは、API で直接設定することもできます。

Console

GCP Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動
[インスタンスを作成] をクリックします。
[新しいインスタンスの作成] ページで、インスタンス向けに希望するプロパティを入力します。

[ID と API へのアクセス] セクションで、使用するサービスアカウントをプルダウンリストから選択します。
[作成] をクリックしてインスタンスを作成します。

gcloud

gcloud コマンドラインツールを使用して、新しいインスタンスを作成し、そのインスタンスがカスタムサービスアカウントとして実行されることを承認するには、サービスアカウントのメールアドレスとインスタンスに必要なアクセススコープを指定します。たいていは、cloud-platform アクセススコープを設定するだけで済みます。仮想マシンインスタンスに付与したアクセススコープとサービスアカウントに付与した IAM 役割の組み合わせにより、インスタンスでサービスアカウントに許可されるアクセスレベルが決まります。サービスアカウントで API メソッドを実行できるのは、アクセススコープと IAM 役割の両方で許可されている場合だけです。

または、サービスが呼び出す特定の API メソッドへのアクセスを承認する特定のスコープの設定を選択することもできます。たとえば、instances.insert メソッドを呼び出すには、https://www.googleapis.com/auth/compute スコープまたは https://www.googleapis.com/auth/cloud-platform スコープを対象とした承認と、このメソッドへのアクセス権を付与する IAM 役割が必要です。cloud-platform スコープの代わりに compute スコープを設定できます。これにより、Compute Engine 内部のメソッドを呼び出すためのサービス承認が付与されますが、Compute Engine の外部の API メソッドを呼び出すための承認は付与されません。

gcloud compute instances create [INSTANCE_NAME] \
    --service-account [SERVICE_ACCOUNT_EMAIL] \
    --scopes [SCOPES,...]

ここで:

[SERVICE_ACCOUNT_EMAIL] は、使用するサービスアカウントのメールアドレスです。例: my-sa-123@my-project-123.iam.gserviceaccount.com。メールアドレスがわからない場合は、サービスアカウントのメールアドレスの取得方法をご覧ください。
[INSTANCE_NAME] はインスタンスの名前です。
[SCOPES] は、完全なスコープ URI または --scopes フラグの説明にあるスコープエイリアスのカンマ区切りのリストです。

次に例を示します。

gcloud compute instances create example-vm \
    --service-account 123-my-sa@my-project-123.iam.gserviceaccount.com \
    --scopes https://www.googleapis.com/auth/cloud-platform

gcloud ツールは、長いスコープ URI の代わりになるスコープエイリアスも提供します。たとえば、Google Cloud Storage への完全アクセス権のスコープは https://www.googleapis.com/auth/devstorage.full_control です。このスコープのエイリアスは storage-full です。

スコープとスコープエイリアスの一覧については、instances create ページの --scopes フラグの説明で確認できます。instances create コマンドのヘルプでも、これらのスコープとエイリアスの一覧が見られます。

gcloud compute instances create --help

エイリアスは、通常のスコープ URI を指定するのと同じ方法で指定します。次に例を示します。

gcloud compute instances create [INSTANCE_NAME] \
    --service-account [SERVICE_ACCOUNT_EMAIL] \
    --scopes cloud-platform

API

API では、インスタンスを作成するための通常のリクエストを作成しますが、serviceAccounts プロパティを含めます。サービスアカウントのメールアドレスを取得して email プロパティに含め、インスタンスに必要なアクセススコープも指定します。たいていは、cloud-platform アクセススコープを設定するだけで済みます。サービスアカウントに付与したアクセススコープと IAM 役割の組み合わせにより、インスタンスでサービスアカウントに許可されるアクセスレベルが決まります。サービスアカウントで API メソッドを実行できるのは、アクセススコープと IAM 役割の両方で許可されている場合だけです。

または、サービスが呼び出す特定の API メソッドへのアクセスを承認する特定のスコープの設定を選択することもできます。たとえば、instances.insert メソッドを呼び出すには、https://www.googleapis.com/auth/compute スコープまたは https://www.googleapis.com/auth/cloud-platform スコープを対象とした承認が必要です。cloud-platform スコープの代わりに compute スコープを設定できます。これにより、Compute Engine 内部のメソッドを呼び出すためのサービス承認が付与されますが、Compute Engine の外部の API メソッドを呼び出すための承認は付与されません。

POST https://www.googleapis.com/compute/v1/projects/zones/[ZONE]/instances
{
  "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/machineTypes/[MACHINE_TYPE]",
  "name": "[INSTANCE_NAME]",
  "serviceAccounts": [
   {
    "email": "[SERVICE_ACCOUNT_EMAIL]",
    "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
   }
  ],
  ...
}

サービスアカウントとして走行するインスタンスを設定すると、次のような方法でインスタンス内からサービスアカウントの認証情報を使用できます。

アプリケーションのデフォルト認証情報とクライアントライブラリを使用すると、アプリケーションを簡単に認証できます。
アプリケーション内で直接アクセストークンをリクエストして使用します。
gcloud や gsutil コマンドを使用します。これらのコマンドはサービスアカウントと有効になっているスコープを自動的に認識して使用します。

サービスアカウントの認証情報を使用したアプリケーションの認証

サービスアカウントとして走行するようにインスタンスを設定した後で、サービスアカウントの認証情報を使用してインスタンス上で走行するアプリケーションを承認することができます。

クライアントライブラリを使用したアプリケーションの認証

クライアントライブラリは、Google API で認証するために、アプリケーションのデフォルト認証情報を使用し、それらの API にリクエストを送信することができます。アプリケーションは、アプリケーションのデフォルト認証情報により、複数のソースから認証情報を取得できるため、アプリケーションをローカルでテストできます。テスト後は、アプリケーションコードを変更することなく、Compute Engine インスタンスにデプロイできます。アプリケーションをローカルで開発する場合、環境変数や Google Cloud SDK を使用してアプリケーションを認証できます。アプリケーションをインスタンス上で実行する場合は、そのインスタンスで有効になっているサービスアカウントを使用してアプリケーションを認証できます。

この例では、Python クライアントライブラリを使用して認証を行い、プロジェクト内のバケットの一覧表示を行う Cloud Storage API にリクエストを行います。この例では、以下の手順を使用します。

Cloud Storage API に必要な認証情報を取得し、build() メソッドと認証情報を使用して Cloud Storage サービスを初期化します。
Cloud Storage 内のバケットをリストします。

このサンプルは、Google Cloud Storage 内のバケットを管理するためのアクセス権があるインスタンス上で実行できます。

compute/auth/application_default.py

GitHub で表示

import argparse

import googleapiclient.discovery

def create_service():
    # Construct the service object for interacting with the Cloud Storage API -
    # the 'storage' service, at version 'v1'.
    # Authentication is provided by application default credentials.
    # When running locally, these are available after running
    # `gcloud auth application-default login`. When running on Compute
    # Engine, these are available from the environment.
    return googleapiclient.discovery.build('storage', 'v1')

def list_buckets(service, project_id):
    buckets = service.buckets().list(project=project_id).execute()
    return buckets

def main(project_id):
    service = create_service()
    buckets = list_buckets(service, project_id)
    print(buckets)

if __name__ == '__main__':
    parser = argparse.ArgumentParser(
        description=__doc__,
        formatter_class=argparse.RawDescriptionHelpFormatter)
    parser.add_argument('project_id', help='Your Google Cloud Project ID.')

    args = parser.parse_args()

    main(args.project_id)

アクセストークンを使用したアプリケーションディレクトリの認証

一部のアプリケーションでは、OAuth2 アクセストークンをリクエストして、クライアントライブラリを介さずにそのアクセストークンを直接使用するか、または、gcloud ツールや gsutil ツールを使用する必要がある場合があります。アプリケーションを認証するために、これらのアクセストークンを取得して使用するためのオプションは複数あります。たとえば、curl を使用してシンプルなリクエストを作成したり、Python などのプログラミング言語を使用して柔軟性を高めたりできます。

cURL

curl を使用してアクセストークンをリクエストして、API にリクエストを送信するには:

アプリケーションが走行するインスタンス上で、次のコマンドによってアクセストークンのメタデータサーバーをクエリします。

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

以下のようなレスポンスが返されます。

{
      "access_token":"ya29.AHES6ZRN3-HlhAPya30GnW_bHSb_QtAS08i85nHq39HE3C2LTrCARA",
      "expires_in":3599,
      "token_type":"Bearer"
 }

レスポンスから access_token プロパティの値をコピーし、その値を使用して API にリクエストを送信します。たとえば、次のリクエストでは、特定のゾーンからプロジェクト内のインスタンスのリストが出力されます。
```
$ curl https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances \
-H "Authorization":"Bearer [ACCESS_TOKEN]"
```
ここで:
- [PROJECT_ID] は、このリクエストのプロジェクト ID です。
- [ZONE] は、インスタンスのリスト元のゾーンです。
- [ACCESS_TOKEN] は、ステップ 1 で取得したアクセストークンの値です。
注: アクセストークンは、インスタンスの作成時に指定したスコープに対してのみ使用できます。たとえば、インスタンスに Google Cloud Storage の https://www.googleapis.com/auth/storage-full スコープのみが付与されている場合、アクセストークンを使用して BigQuery に対するリクエスト作成することはできません。
リクエストに設定可能なパラメータの詳細については、パラメータのドキュメントを参照してください。

Python

この例では、Python アプリケーションで Google Cloud Storage API にアクセスするためにトークンをリクエストする方法を示します。この例では、以下の手順を使用します。

メタデータサーバーのアクセストークンをリクエストします。
サーバーのレスポンスからアクセストークンを抽出します。
アクセストークンを使用して、Google Cloud Storage にリクエストを行います。
リクエストが成功した場合、スクリプトによってレスポンスが出力されます。

compute/auth/access_token.py

GitHub で表示

import argparse

import requests

METADATA_URL = 'http://metadata.google.internal/computeMetadata/v1/'
METADATA_HEADERS = {'Metadata-Flavor': 'Google'}
SERVICE_ACCOUNT = 'default'

def get_access_token():
    url = '{}instance/service-accounts/{}/token'.format(
        METADATA_URL, SERVICE_ACCOUNT)

    # Request an access token from the metadata server.
    r = requests.get(url, headers=METADATA_HEADERS)
    r.raise_for_status()

    # Extract the access token from the response.
    access_token = r.json()['access_token']

    return access_token

def list_buckets(project_id, access_token):
    url = 'https://www.googleapis.com/storage/v1/b'
    params = {
        'project': project_id
    }
    headers = {
        'Authorization': 'Bearer {}'.format(access_token)
    }

    r = requests.get(url, params=params, headers=headers)
    r.raise_for_status()

    return r.json()

def main(project_id):
    access_token = get_access_token()
    buckets = list_buckets(project_id, access_token)
    print(buckets)

if __name__ == '__main__':
    parser = argparse.ArgumentParser(
        description=__doc__,
        formatter_class=argparse.RawDescriptionHelpFormatter)
    parser.add_argument('project_id', help='Your Google Cloud project ID.')

    args = parser.parse_args()

    main(args.project_id)

アクセストークンは短期間で失効します。メタデータサーバーは、失効までの残り時間が 60 秒になるまで、アクセストークンをキャッシュに保存します。新しいトークンは必要に応じてリクエストできますが、アプリケーションには API 呼び出しが成功するための有効なアクセストークンが必要です。

サービスアカウントを使用してインスタンス上のツールを承認する

一部のアプリケーションでは、Compute Engine の大部分のイメージにデフォルトで含まれている gcloud ツールや gsutil ツールのコマンドが使用されることがあります。これらのツールは、インスタンスのサービスアカウントとサービスアカウントに付与されている関連の権限を自動的に認識します。特に、サービスアカウントに正しい役割を付与すると、gcloud auth login を使用せずに、インスタンスから gcloud と gsutil ツールを使用できます。

サービスアカウントの認識は自動的に行われ、インスタンスに含まれている gcloud および gsutil ツールにのみ適用されます。新しいツールを作成したり、カスタムツールを追加したりする場合は、クライアントライブラリを使用するか、アプリケーション内で直接アクセストークンを使用して、アプリケーションを承認する必要があります。

サービスアカウントの自動認識を利用するには、サービスアカウントに適切な IAM の役割を付与し、サービスアカウントとして実行されるようにインスタンスを設定します。たとえば、サービスアカウントに roles/storage.objectAdmin の役割を付与すると、gsutil ツールで、Google Cloud Storage のオブジェクトを自動的に管理してアクセスできます。

同様に、サービスアカウントに対して roles/compute.instanceAdmin.v1 を有効にすると、gcloud compute ツールでインスタンスを自動管理できます。

インスタンスのサービスアカウントとアクセススコープを変更する

VM を別の ID として実行する場合や、必要な API を呼び出すためインスタンスに別のスコープセットが必要であると判断した場合は、既存のインスタンスのサービスアカウントとアクセススコープを変更できます。たとえば、アクセススコープを変更して新しい API へのアクセスを許可したり、インスタンスを変更して Compute Engine のデフォルトのサービスアカウントとしてではなく作成したサービスアカウントとして実行したりできます。

インスタンスのサービスアカウントまたはアクセススコープを変更する場合、インスタンスを一時的に停止する必要があります。インスタンスを停止する方法については、インスタンスの停止をご覧ください。サービスアカウントまたはアクセススコープを変更した後で、インスタンスを再起動してください。

以下のいずれかの方法で、停止したインスタンスのサービスアカウントまたはアクセススコープを変更します。

Console

Compute Engine で [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動
サービスアカウントを変更する VM インスタンスをクリックします。
インスタンスが停止していない場合には、[停止] ボタンをクリックします。インスタンスが停止するまで待機します。
次に、[編集] ボタンをクリックします。
下にスクロールして、[サービスアカウント] セクションに移動します。
プルダウンメニューから、必要なサービスアカウントを選択します。
スコープを変更するには、[アクセススコープ] セクションで、必要に応じて適切なスコープを設定します。ベストプラクティスとして、VM インスタンスに必要なアクセススコープのみを指定します。設定する適切なアクセススコープがわからない場合は、[すべての Cloud API に完全アクセス権を許可] を選択してから、IAM の役割を設定してアクセスを制限してください。
[保存] ボタンをクリックして変更を保存します。

gcloud

コマンド instances set-service-account を使用して、インスタンス名、サービスアカウントのメールアドレス、必要なスコープを指定します。インスタンスからサービスアカウントとアクセススコープを削除することもできます。これにより、インスタンスが Google Cloud Platform サービスにアクセスするのを効率的に回避できます。

 gcloud compute instances set-service-account [INSTANCE_NAME] \
     [--service-account [SERVICE_ACCOUNT_EMAIL] | --no-service-account] \
     [--no-scopes | --scopes [SCOPES,...]]

ここで:

[SERVICE_ACCOUNT_EMAIL] は、使用するサービスアカウントのメールアドレスです。例: my-sa-123@my-project-123.iam.gserviceaccount.com。
[INSTANCE_NAME] はインスタンスの名前です。
[SCOPES] は、完全なスコープ URI または --scopes フラグの説明にあるスコープエイリアスのカンマ区切りのリストです。インスタンスのスコープをすべて削除するには、--no-scopes フラグを使用します。

たとえば、次のコマンドを実行すると、example-instance というインスタンスにサービスアカウント my-sa-123@my-project-123.iam.gserviceaccount.com が割り当てられ、このインスタンスに Compute Engine に対する読み取り / 書き込みアクセスと Google Cloud Storage に対する読み取り専用アクセスを許可するアクセススコープが設定されます。

 gcloud compute instances set-service-account example-instance \
     --service-account my-sa-123@my-project-123.iam.gserviceaccount.com \
     --scopes compute-rw,storage-ro

API

API で、setServiceAccount メソッドに対する POST リクエストを行います。

https://www.googleapis.com/compute/v1/projects[PROJECT_ID]/zones/[ZONE]/instances/[INSTANCE_NAME]/setServiceAccount

ここで:

[PROJECT_ID] は、このリクエストのプロジェクト ID です。
[ZONE] は、このインスタンスが属するゾーンです。
[INSTANCE_NAME] はインスタンスの名前です。

リクエストの本文で、サービスアカウントのメールアドレスとインスタンスに必要なスコープ URI を指定します。

 {
   "email": "[SERVICE_ACCOUNT_EMAIL]",
   "scopes": [
     "[SCOPE_URI]",
     "[SCOPE_URI]",
     ...
 ]}

たとえば、次のリクエストではサービスアカウントのメールアドレス my-sa-123@my-project-123.iam.gserviceaccount.com を使用して、Google Cloud Storage と Google BigQuery のスコープを設定しています。

{
  "email": "my-sa-123@my-project-123.iam.gserviceaccount.com",
  "scopes": [
    "https://www.googleapis.com/auth/bigquery",
    "https://www.googleapis.com/auth/devstorage.read_only"
]}

サービスアカウントのメールアドレスの取得

サービスアカウントを識別するには、サービスアカウントのメールアドレスが必要です。サービスアカウントのメールアドレスは、以下のいずれかのオプションを使用して取得します。

Console

GCP Console の [サービスアカウント] ページに移動します。
[サービスアカウント] ページに移動
プロンプトが表示されたら、プロジェクトを選択します。[サービスアカウント] ページに、そのプロジェクトのすべてサービスアカウントとメールアドレスが一覧表示されます。

gcloud

ローカルマシンで、gcloud compute instances describe コマンドを使用します。

gcloud compute instances describe [INSTANCE_NAME] --format json

 {
       ...
       "serviceAccounts":[
          {
             "email":"123845678986-compute@developer.gserviceaccount.com",
             "scopes":[
                "https://www.googleapis.com/auth/devstorage.full_control"
             ]
          }
       ]
       ...
    }

インスタンスがサービスアカウントを使用していない場合、serviceAccounts プロパティのないレスポンスを受け取ります。

メタデータサーバー

インスタンス内からメタデータサーバーをクエリします。http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/ へのリクエストを行います。

  user@myinst:~$ curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/" \
  -H "Metadata-Flavor: Google"

インスタンスの作成時に 1 つ以上のサービスアカウントを有効にしている場合、この curl コマンドを実行すると、以下のような出力が返されます。

123845678986-compute@developer.gserviceaccount.com/
default/

インスタンスがサービスアカウントを使用していない場合、空のレスポンスが返されます。

API

サービスアカウント API にリクエストを行います。

Compute Engine のデフォルトのサービスアカウントの使用

Compute Engine のデフォルトのサービスアカウントに関する詳しい知識があり、新しいサービスアカウントを作成する代わりにデフォルトのサービスアカウントによって提供される認証情報を使用する場合は、IAM の役割をデフォルトのサービスアカウントに付与することができます。

デフォルトでは、すべての Compute Engine インスタンスは、デフォルトのサービスアカウントとして走行できます。gcloud コマンドラインツールまたは GCP Console を使用してインスタンスを作成し、サービスアカウントの指定を省略した場合は、デフォルトのサービスアカウントがそのインスタンスに割り当てられます。

デフォルトのサービスアカウントに IAM の役割を付与する前に、以下の点を確認してください。

IAM の役割をデフォルトのサービスアカウントに付与すると、デフォルトのサービスアカウントとして走行中のすべてのインスタンスに影響を及ぼします。たとえば、デフォルトのサービスアカウントに roles/storage.objectAdmin の役割を付与すると、必要なアクセススコープが指定されたデフォルトのサービスアカウントとして走行しているすべてのインスタンスが roles/storage.objectAdmin の役割によって付与される権限を持ちます。同様に、特定の役割を省略してアクセス権限を制限すると、デフォルトのサービスアカウントとして走行中のすべてのインスタンスに影響を及ぼします。
サービスアカウントのプロジェクト編集者の権限は取り消す必要があります。デフォルトのサービスアカウントは、デフォルトでプロジェクト編集者としてプロジェクトに追加されます。IAM の役割を使用するには、プロジェクト編集者の権限を取り消す必要があります。

IAM の役割をデフォルトのサービスアカウントに付与すべきかわからない場合は、代わりに新しいサービスアカウントを作成する必要があります。

注意: 現在デフォルトのサービスアカウントを使用し編集者のアクセス権に依存している既存のインスタンスがある場合、このプロセスでは、そのアカウントに対する編集者のアクセス権を取り消す必要があります。編集者の権限に依存しているインスタンスは、他の Google API にアクセスするための権限を使用できません。ほとんどの Google Cloud Platform プロダクトは、IAM の役割を提供するので、役割を付与すればプロジェクト編集者によって提供されるアクセス権を複製することができます。しかし、場合によっては特定の API が IAM の役割をまだサポートしていないことがあります。そのような場合には、当分の間プロジェクト編集者の役割に依存する必要があります。

IAM の役割をデフォルトのサービスアカウントに付与するには、次の手順に従います。

GCP Console の IAM ページに移動します。
IAM ページに移動
プロンプトが表示されたら、プロジェクトを選択します。
Compute Engine のデフォルトのサービスアカウントという名前のサービスアカウントを探します。
[役割] 列で、Compute Engine のデフォルトのサービスアカウントのプルダウンメニューを展開します。
編集者のアクセス権を削除して、変更を保存します。
次に、サービスアカウントに IAM の役割を付与します。

現在デフォルトのサービスアカウントとして走行しているすべての仮想マシンインスタンスが、アカウントに付与した IAM の役割に従って他の Google Cloud Platform API にアクセスできるようになります。

デフォルトのサービスアカウントとして走行する新しいインスタンスを設定する場合の手順は次のとおりです。

Console

GCP Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動
[インスタンスを作成] をクリックします。
[新しいインスタンスの作成] ページで、インスタンス向けに希望するプロパティを入力します。

[ID と API へのアクセス] セクションで、プルダウンリストから [Compute Engine のデフォルトのサービスアカウント] を選択します。
[作成] をクリックしてインスタンスを作成します。

gcloud

新しいインスタンスを作成し、そのインスタンスがデフォルトのサービスアカウントを使用してすべての Google Cloud Platform サービスに対する完全アクセス権を持つことを承認するには:

gcloud compute instances create [INSTANCE_NAME] \
     --scopes cloud-platform

API

API では、インスタンスを作成するための通常のリクエストを作成しますが、serviceAccounts プロパティを含めます。デフォルトのサービスアカウント ID を取得し、サービスアカウントの email として含めます。次に、scopes プロパティに 1 つ以上のスコープを設定します。

POST https://www.googleapis.com/compute/v1/projects/zones/[ZONE]/instances
{
  "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/machineTypes/[MACHINE_TYPE]",
  "name": "[INSTANCE_NAME]",
  "serviceAccounts": [
   {
    "email": "[DEFAULT_SERVICE_ACCOUNT_EMAIL]",
    "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
   }
  ],
  ...
}

ベストプラクティス

インスタンスで Google API を呼び出す必要がある場合、Google では、そのジョブの実行に必要な最低限の権限のみを持つサービスアカウントとしてインスタンスを実行することをおすすめしています。次のプロセスでインスタンスのサービスアカウントを設定してください。

Compute Engine のデフォルトのサービスアカウントを使用せずに、新しいサービスアカウントを作成します。
必要なリソースについてのみ、このサービスアカウントに IAM 役割を付与します。
このサービスアカウントとして走行するようにインスタンスを設定します。
インスタンスに https://www.googleapis.com/auth/cloud-platform スコープを付与します。

必要以上のアクセス権を付与しないように、サービスアカウントの権限を定期的に確認し、最新の状態にしてください。

次のステップ

サービスアカウントの詳細を確認する。
Compute Engine IAM の役割の詳細を確認する。

インスタンスのサービス アカウントの作成と有効化

始める前に

新しいサービス アカウントを作成する

新しいインスタンスをサービス アカウントとして走行するように設定する

Console

gcloud

API

サービス アカウントの認証情報を使用したアプリケーションの認証

クライアント ライブラリを使用したアプリケーションの認証

アクセス トークンを使用したアプリケーション ディレクトリの認証

cURL

Python

サービス アカウントを使用してインスタンス上のツールを承認する

インスタンスのサービス アカウントとアクセス スコープを変更する

Console

gcloud

API

サービス アカウントのメールアドレスの取得

Console

gcloud

メタデータ サーバー

API

Compute Engine のデフォルトのサービス アカウントの使用

Console

gcloud

API

ベスト プラクティス

次のステップ

フィードバックを送信...

新しいサービスアカウントを作成する

新しいインスタンスをサービスアカウントとして走行するように設定する

サービスアカウントの認証情報を使用したアプリケーションの認証

クライアントライブラリを使用したアプリケーションの認証

アクセストークンを使用したアプリケーションディレクトリの認証

サービスアカウントを使用してインスタンス上のツールを承認する

インスタンスのサービスアカウントとアクセススコープを変更する

サービスアカウントのメールアドレスの取得

メタデータサーバー

Compute Engine のデフォルトのサービスアカウントの使用

ベストプラクティス