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

インスタンスで実行するアプリでは、サービスアカウントを介して Google Cloud APIs を操作できます。サービスアカウントに適切な Compute Engine IAM のロールがあれば、アプリのコードから特定の API リクエストを実行できます。

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

始める前に

このガイドのコマンドラインの例を使用する場合は、次の操作を行います。
1. gcloud コマンドラインツールの最新バージョンをインストールするか、最新バージョンに更新します。
2. デフォルトのリージョンとゾーンを設定します。
このガイドの API の例を使用する場合、API アクセスを設定します。
サービスアカウントの概要をご覧ください。

新しいサービスアカウントの作成

IAM を使用して新しいサービスアカウントを作成し、設定できます。アカウントを作成した後で、1 つ以上の IAM のロールをアカウントに付与し、そのサービスアカウントとして実行する仮想マシンインスタンスを承認します。

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

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

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

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

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

通常は、cloud-platform アクセススコープを設定してほとんどの Cloud APIs に対するアクセスを許可してから、関連する IAM ロールのみをサービスアカウントに付与できます。仮想マシンインスタンスに付与したアクセススコープとサービスアカウントに付与されている 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 メソッドを呼び出すためのアクセスは付与されません。

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

Console

[インスタンスの作成] ページに移動します。

[インスタンスの作成] に移動
VM の詳細を指定します。
[ID と API へのアクセス] セクションで、使用するサービスアカウントをプルダウンリストから選択します。
VM 作成プロセスを続行します。

gcloud

gcloud コマンドラインツールを使用して、新しいインスタンスを作成し、カスタムサービスアカウントとして実行することを承認するには、サービスアカウントのメールアドレスとインスタンスに必要なアクセススコープを指定します。

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 の代わりになるスコープエイリアスも提供します。たとえば、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 プロパティに含めます。

POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/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 インスタンスにデプロイできます。アプリケーションをローカルで開発する際に、環境変数や Cloud SDK を使用してアプリケーションを認証できます。アプリケーションをインスタンス上で実行する場合は、そのインスタンスで有効になっているサービスアカウントを使用してアプリケーションを認証できます。

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

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

このサンプルは、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://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances \
-H "Authorization":"Bearer [ACCESS_TOKEN]"
```
ここで
- [PROJECT_ID] は、このリクエストのプロジェクト ID です。
- [ZONE] は、インスタンスのリスト元のゾーンです。
- [ACCESS_TOKEN] は、ステップ 1 で取得したアクセストークンの値です。
注: アクセストークンは、インスタンスの作成時に指定したスコープに対する場合に限り使用できます。たとえば、インスタンスに Cloud Storage の https://www.googleapis.com/auth/storage-full スコープのみが付与されている場合、アクセストークンを使用して BigQuery に対するリクエスト作成することはできません。
リクエストに設定可能なパラメータの詳細については、パラメータのドキュメントを参照してください。

Python

この例では、Python アプリケーションで Cloud Storage API にアクセスするためにトークンをリクエストする方法を示します。これは、次の手順により行います。

メタデータサーバーのアクセストークンをリクエストします。
サーバーのレスポンスからアクセストークンを取り出します。
アクセストークンを使用して 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)

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

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

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

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

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

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

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

VM を別の ID として実行する場合や、必要な API を呼び出すためインスタンスに別のスコープセットが必要であると判断した場合は、既存のインスタンスのサービスアカウントとアクセススコープを変更できます。たとえば、アクセススコープを変更して新しい API へのアクセスを許可できます。サービスアカウントとアクセススコープを削除して、VM が Google Cloud サービスにアクセスできないようにすることもできます。また、VM を Compute Engine のデフォルトサービスアカウントではなく、作成したサービスアカウントとして実行するように変更することも可能です。ただし、アクセススコープに依存するのではなく、きめ細かい IAM ポリシーを使用して、サービスアカウントのリソースアクセスを制御することをおすすめします。

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

Console

[VM インスタンス] ページに移動します。

[VM インスタンス] に移動
サービスアカウントを変更する VM インスタンスの名前をクリックします。
インスタンスが停止していない場合には、[停止] をクリックします。インスタンスが停止するまで待機します。
[編集] をクリックします。
下にスクロールして、[サービスアカウント] セクションに移動します。
プルダウンリストから、インスタンスに割り当てるサービスアカウントを選択します。
- デフォルトのサービスアカウントを選択した場合は、Cloud Console でアクセススコープを変更できます。
  - スコープを変更するには、[アクセススコープ] セクションで、[各 API にアクセス権を設定] を選択して、必要に応じて適切なスコープを設定します。
  - 設定する適切なアクセススコープがわからない場合は、[すべての Cloud API に完全アクセス権を許可] を選択してから、サービスアカウントに IAM ロールを設定してアクセスを制限してください。
- 別のサービスアカウントを選択した場合、VM のアクセススコープはデフォルトで cloud-platform になります。スコープを変更するには、gcloud ツールまたは Compute Engine API を使用します。
- アクセススコープの設定の詳細については、ベストプラクティスをご覧ください。
[保存] をクリックして、変更を保存します。

gcloud

instances set-service-account コマンドを使用して、インスタンス名、サービスアカウントのメールアドレス、必要なスコープを指定します。アクセススコープの設定の詳細については、ベストプラクティスをご覧ください。

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 に対する読み取り / 書き込みアクセスと 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://compute.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 を使用して、Cloud Storage と 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

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

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

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 コマンドラインツールまたは Cloud Console を使用してインスタンスを作成し、サービスアカウントの指定を省略した場合は、デフォルトのサービスアカウントがそのインスタンスに割り当てられます。

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

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

デフォルトのサービスアカウントに IAM ロールを付与すべきかどうか判断できない場合は、代わりに新しいサービスアカウントを作成します。

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

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

Google Cloud Console の [IAM] ページに移動します。

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

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

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

Console

[インスタンスの作成] ページに移動します。

[インスタンスの作成] に移動
VM の詳細を指定します。
[ID と API へのアクセス] セクションで、[サービスアカウント] プルダウンリストから [Compute Engine default service account] を選択します。
VM 作成プロセスを続行します。

gcloud

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

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

API

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

POST https://compute.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"]
   }
  ],
  ...
}

ベストプラクティス

VM インスタンスで Google API を呼び出す必要がある場合、Google では、そのジョブの実行に必要な最低限の権限のみを持つサービスアカウントとして VM を実行することをおすすめしています。
次の手順に沿って VM のサービスアカウントを構成します。
1. Compute Engine のデフォルトのサービスアカウントを使用せずに、新しいサービスアカウントを作成します。
2. 必要なリソースについてのみ、このサービスアカウントに IAM ロールを付与します。
3. 作成した新しいサービスアカウントとして実行するように VM を構成します。
4. VM に https://www.googleapis.com/auth/cloud-platform スコープを付与して、すべての Google Cloud APIs への完全アクセス権を許可します。これにより、VM の IAM 権限は、VM のサービスアカウントに付与した IAM ロールによって完全に決定されます。サービスアカウントは、アクセススコープとサービスアカウント固有の IAM ロールで許可されている API メソッドのみを実行できます。
サービスアカウントの権限を制限して、サービスアカウントの権限を定期的に確認し、最新の状態にします。
サービスアカウントの削除は慎重に行ってください。サービスアカウントを削除する前に、重要なアプリケーションがそのサービスアカウントを使用していないことを確認してください。サービスアカウントが使用されているかどうかわからない場合は、削除するのではなく、サービスアカウントを無効にすることをおすすめします。無効になっているサービスアカウントがまだ必要である場合は、再度有効にすることができます。
サービスアカウントのセキュリティリスクを軽減します。詳しくは、サービスアカウントを保護するためのベストプラクティスをご覧ください。

次のステップ

使ってみる

Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオで Compute Engine のパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Compute Engine の無料トライアル

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

始める前に

新しいサービス アカウントの作成

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

Console

gcloud

API

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

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

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

cURL

Python

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

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

Console

gcloud

API

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

Console

gcloud

メタデータ サーバー

API

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

Console

gcloud

API

ベスト プラクティス

次のステップ

使ってみる

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

新しいサービスアカウントの作成

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

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

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

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

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

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

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

メタデータサーバー

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

ベストプラクティス