GSP647

概要

このラボでは、IAM と gcloud を理解できるように、以下の一般的な 3 つの領域を見ていきます。

• gcloud 環境の構成
• 複数の gcloud 構成の使用
• サービス アカウントの使用

このラボでは、CLI ツールの gcloud を使用して、Cloud Identity and Access Management（IAM）のコマンド機能を設定および構成します。

学習内容

このラボでは、次のことを行います。

• IAM をレビューし、gcloud クライアントを使用する
• 複数の IAM 構成を作成し、構成間を切り替える
• 適切な IAM 権限を特定して割り当てる
• サービス アカウントを作成して使用する

開始時の環境

2 つのユーザー アカウントと 2 つのプロジェクトを使用して作業を開始します。

• user1 は両方のプロジェクトの「owner」
• user2 は最初のプロジェクトのみの「viewer」

最初のプロジェクトでは、Linux 仮想マシン（vm）が実行されています。

IAM とは

Google Cloud では、Cloud Identity and Access Management（IAM）を利用できます。誰（ID）がどのリソースにどのようなアクセスが可能か（ロール）を定義することで、アクセス制御を管理できます。

IAM では、リソースに対するアクセス権を直接エンドユーザーに付与することはありません。複数の権限をロールにまとめて、認証されたプリンシパルに付与します。これまで、IAM ではプリンシパルをメンバーと呼んでいました。一部の API では、まだこの用語が使用されています。

ID

Cloud IAM では、プリンシパルに対してアクセス権を付与します。プリンシパルには次のタイプがあります。

• Google アカウント
• サービス アカウント
• Google グループ
• Google Workspace アカウント
• Cloud Identity ドメイン
• 認証済みのすべてのユーザー
• すべてのユーザー

これらの ID タイプの詳細については、ID に関するコンセプトのガイドをご覧ください。

このラボでは、Google アカウント、サービス アカウント、Cloud Identity ドメイン グループを使用します。

ロール

ロールとは、一連の権限のことです。ユーザーには権限を直接割り当てるのではなく、ロールを付与します。ロールをユーザーに付与すると、そのロールに含まれているすべての権限がユーザーに付与されます。

ロールの詳細については、ロールのガイドをご覧ください。

gcloud とは

gcloud CLI は Cloud SDK の一部です。gcloud コマンドライン ツールを使用するには、システムに SDK をダウンロードしてインストールし、初期化する必要があります。このツールを使用すると、コマンドラインからだけでなく、スクリプトやその他の自動化機能からも、多くの一般的なプラットフォーム タスクを実行できます。

gcloud の詳細については、gcloud CLI の概要のガイドをご覧ください。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。 注: このラボでは、Username 1 を使用してログインします。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。 左側の [ラボの詳細] ペインには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] ペインでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] ペインでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

タスク 1. gcloud 環境を構成する

このラボには、centos-clean という Compute Engine インスタンスがすでに設定され、gcloud がまだインストールされていない環境をシミュレートするようになっています。Google Cloud コンソールを使用してこのインスタンスに接続します。

1. ナビゲーション メニュー > [Compute Engine] > [VM インスタンス] に移動して、コンピューティング インスタンスのリストを開きます。

2. centos-clean という名前のコンピューティング インスタンスがある行で、[SSH] をクリックします。

注: Compute Engine インスタンスについて: Windows タイプと Linux タイプのインスタンスがあります。このラボでは、Linux インスタンス タイプを使用します。ウェブブラウザから Secure Shell（SSH）クライアントを使用して、Linux インスタンスに簡単に接続できます。

インスタンスに自動的に接続されます。認証キーは Google Cloud によって安全に管理され、使用できるのはアクセスを許可した対象のみに限られます。

3. まずテストし、バージョンを調べて gcloud が正常にインストールされたことを確認します。SSH セッション内で、以下を実行します。

gcloud --version

新しいインスタンスを作成し、デフォルトのゾーンを更新する

gcloud コマンドライン ツールがインストールされていることを確認したら、コンピューティング インスタンスを作成して、いくつか変更を加えます。

1. まず、gcloud での認証を行います。SSH セッション内で、次を実行します。

gcloud auth login

[Do you want to continue (Y/n)?] プロンプトが表示されたら、Eenter キーを押します。

2. 新しいタブに表示されているリンクに移動します。

3. アクティブなユーザー名（）をクリックし、[Allow] をクリックします。

4. [Enter the following verification code in gcloud CLI on the machine you want to log into] プロンプトが表示されたら、コピーボタンをクリックして SSH セッションに戻り、コピーしたコードを [Enter authorization code:] プロンプトに貼り付けます。

5. SSH セッションで、リージョンとゾーンを設定します。

gcloud config set compute/region {{{project_0.default_region_1 | "Region1"}}} gcloud config set compute/zone {{{project_0.default_zone_1 | "Zone1"}}}

6. SSH セッション内で、以下を実行します。

gcloud compute instances create lab-1 --zone {{{project_0.default_zone_1 | "Zone1"}}} --machine-type=e2-standard-2

すべてを正しく設定すれば、インスタンスが作成されます。

ですが、サイズはどのくらいで、どこに作成され、どのようなイメージが使用されているのでしょうか。

サービスが使用するデフォルトは数多くあります。一部は、gcloud 構成で制御できます。たとえば、インスタンスのロケーションはゾーン設定で制御します。

Project 1 に lab-1 という名前でインスタンスを作成する

8. 現在の gcloud 構成を確認します。SSH セッション内で、以下を実行します。

gcloud config list

compute セクション、core セクション、active configuration が表示されるようになります。これらはそれぞれ変更できますが、このラボではゾーンのみを変更します。VM が作成されたゾーンを確認してください。

9. SSH セッション内で以下を実行して、使用可能なゾーンをすべてリストに表示します。

gcloud compute zones list

10. 自分と同じリージョンにある他のゾーンを 1 つ特定します。たとえば、現在のゾーンが us-west2-a であれば、us-west2-b を選択できます。

11. 現在のゾーンを同じリージョンの別のゾーンに変更します。SSH セッション内で以下を実行し、ZONE をその選択したゾーンに置き換えます。

gcloud config set compute/zone ZONE

12. ゾーンが変更されたことを確認します。SSH セッション内で、以下を実行します。

gcloud config list

指定した変更が指定したゾーンに反映されます。

gcloud config set コマンドを使用して、他の設定を変更できます。こうした変更は永続的です。つまり、ホーム ディレクトリに書き込まれます。

デフォルトの構成は、~/.config/gcloud/configurations/config_default に保存されます。

インスタンスを作成するときにデフォルト以外のゾーンを使用する場合は、--zone switch を使用できます。たとえば、gcloud compute instances create lab-1 --zone us-central1-f とします。

デフォルトのゾーンを更新する

13. ゾーンが構成ファイルに書き込まれたことを確認します。SSH セッション内で、以下を実行します。

cat ~/.config/gcloud/configurations/config_default

構成はテキストとして保存されているだけなので、バックアップやコピーが可能です。

タスク 2. 複数の IAM 構成を作成し、構成間を切り替える

現在設定されているアカウントは 1 つです。さまざまなチームでの業務やさまざまなアカウントへのアクセスが必要になる状況では、gcloud config でそうした状況を管理することもできます。

次のタスクでは、構成をもう一つ作成し、両方の構成を切り替える方法を学びます。

新しい IAM 構成を作成する

このラボでは、ログオンに使用できる Google アカウントをもう一つ作成します。このアカウントは、読み取り専用（viewer）で最初のプロジェクトにアクセスできます。そのユーザー用に新しい構成を作成します。

1. 2 つ目のユーザー アカウント用に新しい gcloud 構成を開始します。SSH セッション内で、以下を実行します。

gcloud init --no-launch-browser

2. オプション 2 の [Create a new configuration] を選択します。

3. 構成名として「user2」と入力します。

4. 新しいアカウントでログインします。オプション 3 を選択して、指定されたもう一方のユーザー名でログインします。

5. [Do you want to continue (Y/n)?] プロンプトが表示されたら、Eenter キーを押します。

6. 新しいタブに表示されているリンクに移動します。

7. [Use another account] をクリックします。

8. 2 つ目のユーザー アカウント（）をコピーして、[email or phone] プロンプトに貼り付けます。

9. ラボを起動したのと同じパスワードをコピーして、[enter your password] プロンプトに貼り付けます。

10. [I understand] をクリックします。

11. [Allow] をクリックします。

これで、Cloud SDK に Google アカウントと同じアクセス権を付与することに同意したことになります。

12. [Enter the following verification code in gcloud CLI on the machine you want to log into] プロンプトが表示されたら、コピーボタンをクリックして SSH セッションに戻り、コピーしたコードを [Enter authorization code:] プロンプトに貼り付けます。

13. [Pick cloud project to use:] では、現在のプロジェクト（）を特定し、そのプロジェクトに対応する番号を入力します。

初期化が完了し、ゾーンとリージョンが設定されます。

gcloud user2 構成が作成されたことを確認する

新しいアカウントをテストする

この新しいアカウントにはプロジェクトに対する viewer のみの権限が付与されているため、なんらかのリソースを表示し、作成を試みることで、このアカウントを本当に使用していることをテストできます。

1. 最初のプロジェクトで詳細を表示できることを確認します。SSH セッション内で、以下を実行します。

gcloud compute instances list

2 つ目のユーザー アカウントには viewer 権限が付与されているため、centos-clean インスタンスと lab-1 インスタンスがリストに表示されるはずです。

2. 割り当てられたロールが基本的な viewer であるため、最初のプロジェクトではインスタンスを作成できないことを確認します。SSH セッション内で、以下を実行します。

gcloud compute instances create lab-2 --zone {{{project_1.default_zone_1 | "Zone2"}}} --machine-type=e2-standard-2

2 つ目のユーザー アカウントには viewer 権限のみが付与されているため、インスタンスの作成は許可されず、このコマンドは失敗します。失敗するまでに少し時間がかかります。

3. 最初のユーザーの構成（デフォルト）に戻します。SSH セッション内で、以下を実行します。

gcloud config configurations activate default

元のユーザー アカウント認証情報を使用している状態に戻ります。後で、ロールと権限について学習する際に、この 2 つのアカウントを切り替えることになります。

タスク 3. 適切な IAM 権限を特定して割り当てる

このプロジェクトでは 2 つのユーザー アカウントを使用します。最初のユーザーは、両方のプロジェクトを完全に制御できるので、管理者アカウントと考えることができます。2 人目のユーザーは、2 つのプロジェクトに対して viewer のみの権限を持っています。2 人目のユーザーを DevOps ユーザーと呼ぶことにします。そのユーザー ID は、一般的な DevOps レベルのユーザーを表します。

次に、gcloud を使用して、DevOps ユーザー用に 1 つのプロジェクトへのアクセスを構成します。具体的には、そのプロジェクトに対して、バケットとインスタンスの作成を許可するカスタムロールを作成します。

ロールと権限を確認する

1. すべてのロールを表示するには、SSH セッション内で以下を実行します。

gcloud iam roles list | grep "name:"

ロールのリストが返されます。コマンドに grep "name:" を追加すると、返されるデータがロール名だけになり、データ量が減ります。

返されたロールのいずれかを調べて、そのロールに割り当てられた権限を確認します。権限を表示するには、gcloud iam roles describe を使用します。ここでは、roles/compute.instanceAdmin という簡単なロールを見てみてください。

2. compute.instanceAdmin 事前定義ロールを確認します。SSH セッション内で、以下を実行します。

gcloud iam roles describe roles/compute.instanceAdmin

roles/compute.instanceAdmin には数多くの権限がありますが、後で少なくともこれらの権限が必要になります。

• compute.instances.create
• compute.instances.delete
• compute.instances.start
• compute.instances.stop
• compute.instances.update
• compute.disks.create
• compute.subnetworks.use
• compute.subnetworks.useExternalIp
• compute.instances.setMetadata
• compute.instances.setServiceAccount

ロールの詳細なリストと割り当てられた権限をレビューするには、IAM 権限のリファレンスのガイドをご覧ください。

2 人目のユーザーに 2 つ目のプロジェクトへのアクセスを許可する

これで、ロールに権限が含まれていることを理解しました。では、ロール（および関連付けられているすべての権限）をユーザー アカウントに付与するにはどうすればよいでしょうか。

ロールをアタッチするには、次の 2 つの方法があります。

• ユーザーと組織に付与する
• ユーザーとプロジェクトに付与する

次は、「viewer」という基本ロールを 2 つ目のプロジェクトの 2 人目のユーザーにアタッチします。

2 人目のユーザーには、2 つ目のプロジェクトへのアクセス権がないことをテストで確認します。

1. gcloud 構成を 2 人目のユーザー（user2）に戻します。SSH セッション内で、以下を実行します。

gcloud config configurations activate user2

user2 に戻りました。

2. 2 つ目のプロジェクトに PROJECTID2 を設定します。SSH セッション内で、以下を実行します。

echo "export PROJECTID2={{{project_1.project_id | "PROJECT_ID"}}}" >> ~/.bashrc . ~/.bashrc gcloud config set project $PROJECTID2 注: このコマンドは bashrc ファイルを追加するため、十分に留意してください。

WARNING: You do not appear to have access to project [your 2nd project id] or it does not exist. という警告が返されます。

3. [Do you want to continue (Y/n)?] プロンプトが表示されたら、「N」と入力して Enter キーを押します。

つまり、user2 には PROJECTID2 プロジェクトへのアクセス権がありません。この点については、次のセクションで修正します。

2 つ目のプロジェクトの 2 人目のユーザーに viewer ロールを割り当てる

1. デフォルトの gcloud 構成に戻します。この構成には 2 人目のユーザーにアクセスを許可する権限があります。SSH セッション内で、以下を実行します。

gcloud config configurations activate default

2. jq をインストールします。

sudo yum -y install epel-release sudo yum -y install jq

次に、2 人目のユーザー名に USERID2 という値を設定し、2 つ目のプロジェクトの 2 人目のユーザーに viewer のロールをバインドします。

3. SSH セッション内で、以下を実行します。

echo "export USERID2={{{user_1.username | "Username2"}}}" >> ~/.bashrc . ~/.bashrc gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=roles/viewer

コマンドを実行すると、次のようなテキストが表示されます（上にスクロールすることが必要になる場合があります）。

Updated IAM policy for project [{{{project_1.project_id | "PROJECT_ID"}}}]. bindings: ... - members: - serviceAccount:{{{project_1.project_id | "PROJECT_ID"}}}@{{{project_1.project_id | "PROJECT_ID"}}}.iam.gserviceaccount.com role: roles/storage.admin - members: - user:{{{user_0.username | "Username1"}}} - user:{{{user_1.username | "Username2"}}} role: roles/viewer Username 2 を Project 2 の roles/viewer に限定する

タスク 4. user2 にアクセス権があることをテストで確認する

1. gcloud 構成を user2 に切り替えます。SSH セッション内で、以下を実行します。

gcloud config configurations activate user2

2. user2 の構成を 2 つ目のプロジェクトに変更します。SSH セッション内で、以下を実行します。

gcloud config set project $PROJECTID2

今回はエラー メッセージが表示されないはずです。

3. viewer 権限が付与されたことを確認します。SSH セッション内で、以下を実行します。

gcloud compute instances list

このプロジェクトではインスタンスが 0 個だと表示されます。

4. 2 人目のユーザーとして 2 つ目のプロジェクトにインスタンスを作成してみます。SSH セッション内で、以下を実行します。

gcloud compute instances create lab-2 --zone {{{project_1.default_zone_1 | "Zone2"}}} --machine-type=e2-standard-2

user2 にはこのプロジェクトに対して viewer 権限のみが付与されているため、このコマンドは失敗します。

5. gcloud 構成をデフォルトに切り替えます。SSH セッション内で、以下を実行します。

gcloud config configurations activate default

元のユーザー アカウントの認証情報を使用している状態に戻ります。

権限のある新しいロールを作成する

次に、DevOps チームに必要な権限セットを付与した新しいロールを作成します。

• インスタンスを作成する権限があるカスタムロールを devops という名前で作成します。SSH セッション内で、以下を実行します。

gcloud iam roles create devops --project $PROJECTID2 --permissions "compute.instances.create,compute.instances.delete,compute.instances.start,compute.instances.stop,compute.instances.update,compute.disks.create,compute.subnetworks.use,compute.subnetworks.useExternalIp,compute.instances.setMetadata,compute.instances.setServiceAccount"

このコマンドは、インスタンスを作成および管理する権限があるカスタムロールを devops という名前でプロジェクトに作成します。

ロールのフルネームはリストで確認できます。なお、ロールはプロジェクト内にあるため、パスが projects/PROJECT/roles/ROLENAME というパターンになることに留意してください。

DevOps チーム向けの権限がある新しいロールを作成する

両方のプロジェクトで 2 つ目のアカウントにロールをバインドする

ロールを作成したので、次はプロジェクトにユーザーとロールをバインドする必要があります。gcloud projects add-iam-policy-binding を使用して、バインドを実行します。このコマンドを簡単に実行できるように、まず、プロジェクト ID とユーザー アカウントの 2 つの環境変数を設定します。

1. 2 つ目のプロジェクトで iam.serviceAccountUser というロールを 2 人目のユーザーにバインドします。SSH セッション内で、以下を実行します。

gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=roles/iam.serviceAccountUser

アタッチされたサービス アカウントでインスタンスを作成できる権限が必要です。ロール iam.serviceAccountUser にはその権限があるため、この事前定義ロールを使用します。

user2 が project2 とロール roles/iam.serviceAccountUser にバインドされていることを確認する

2. 2 つ目のプロジェクトでカスタムロール devops を 2 人目のユーザーにバインドします。2 つ目のユーザー アカウントは、このページの左側で確認できます。2 つ目のユーザー アカウントに USERID を設定していることを確認してください。

SSH セッション内で、以下を実行します。

gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=projects/$PROJECTID2/roles/devops

コマンドを実行すると、次のようなテキストが表示されます（上にスクロールすることが必要になる場合があります）。

Updated IAM policy for project [{{{project_1.project_id | "PROJECT_ID"}}}]. bindings: - members: - user:{{{user_1.username | "Username2"}}}@qwiklabs.net role: projects/{{{project_1.project_id | "PROJECT_ID"}}}/roles/devops Username 2 を devops ロールにバインドする

新規に割り当てられた権限をテストする

1. gcloud 構成を user2 に切り替えます。SSH セッション内で、以下を実行します。

gcloud config configurations activate user2

user2 に戻りました。

2. インスタンスを lab-2 という名前で作成してみます。SSH セッション内で、以下を実行します。

gcloud compute instances create lab-2 --zone {{{project_1.default_zone_1 | "Zone2"}}} --machine-type=e2-standard-2

user2 のインスタンスが正常に作成されます。

Project 2 に lab-2 という名前でインスタンスを作成する

3. インスタンスが存在することを確認します。SSH セッション内で、以下を実行します。

gcloud compute instances list

ご使用の環境

この最後の変更の後、環境は以下のようになります。

タスク 5. サービス アカウントを使用する

ここまでは、gcloud を認証して使用し、ロールに応じて Google Cloud サービスにアクセスする方法を見てきました。次は、一般的なアプローチを見ていきます。

アプリケーションからアプリケーション プログラミング インターフェース（API）を使用して、Cloud Storage バケットを読み書きできます。新しいサーバーを起動するたびに認証すると、手間がかかるうえ、クラウドを使用する意義が損なわれます。このため、サービス アカウントを使用します。

サービス アカウントは、個々のエンドユーザーではなく、アプリケーションや仮想マシン（VM）に属している特別な Google アカウントです。アプリケーションはサービス アカウントを使用してサービスの Google API を呼び出します。ユーザーは直接的には関与しません。

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

ここからは、サービス アカウントを作成してコンピューティング インスタンスで使用します。その後、必要なアクセスをそのサービス アカウントで許可できることを確認します。

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

1. gcloud 構成をデフォルトに切り替えます。user2 にはサービス アカウントを設定して構成する権限はありません。SSH セッション内で、以下を実行します。

gcloud config configurations activate default

2. ご使用の構成でプロジェクトを PROJECTID2 に設定します。SSH セッション内で、以下を実行します。

gcloud config set project $PROJECTID2

適切なプロジェクトをターゲティングしていることを確認してください。

3. サービス アカウントを作成します。SSH セッション内で、以下を実行します。

gcloud iam service-accounts create devops --display-name devops 作成した devops サービス アカウントを確認する

4. サービス アカウントのメールアドレスを取得します。SSH セッション内で、以下を実行します。

gcloud iam service-accounts list --filter "displayName=devops" 注: このフィルタを適用すると、目的の行のみが表示されます。メールアドレスにはロール名とプロジェクト ID が含まれていることに注意してください。

5. メールアドレスを SA というローカル変数に代入します。SSH セッション内で、以下を実行します。

SA=$(gcloud iam service-accounts list --format="value(email)" --filter "displayName=devops")

このコマンドは、SA ローカル変数をサービス アカウントのメールアドレスに設定するため、かなり便利です。

6. サービス アカウントに iam.serviceAccountUser というロールを付与します。SSH セッション内で、以下を実行します。

gcloud projects add-iam-policy-binding $PROJECTID2 --member serviceAccount:$SA --role=roles/iam.serviceAccountUser

このロールが付与されたサービス アカウントでは、コンピューティング インスタンスにサービス アカウントを割り当てることができます。

devops サービス アカウントが project2 とロール roles/iam.serviceAccountUser にバインドされていることを確認する

タスク 6. コンピューティング インスタンスでサービス アカウントを使用する

1. サービス アカウントに compute.instanceAdmin というロールを付与します。SSH セッション内で、以下を実行します。

gcloud projects add-iam-policy-binding $PROJECTID2 --member serviceAccount:$SA --role=roles/compute.instanceAdmin

このロールが付与されたサービス アカウントでは、コンピューティング インスタンスを管理できます。

devops サービス アカウントが project2 とロール roles/compute.instanceAdmin にバインドされていることを確認する

2. アタッチされた devops サービス アカウントでインスタンスを作成します。また、アクセス スコープを指定する必要があります。このスコープによって、インスタンスが実行できる API 呼び出しを定義します。SSH セッション内で、以下を実行します。

gcloud compute instances create lab-3 --zone {{{project_1.default_zone_1 | "Zone2"}}} --machine-type=e2-standard-2 --service-account $SA --scopes "https://www.googleapis.com/auth/compute"

アクセス スコープは、インスタンスの権限を指定する従来からの方法です。アクセス スコープはセキュリティ メカニズムではなく、gcloud ツールまたはクライアント ライブラリからのリクエストで使用されるデフォルトの OAuth スコープを定義します。これは、gRPC や SignBlob API など、OAuth を介して認証されないリクエストには影響しません。

サービス アカウントとして実行するインスタンスの構成時にアクセス スコープを設定する必要があります。

インスタンスに完全な cloud-platform アクセス スコープを設定し、サービス アカウントに IAM ロールを付与してサービス アカウントの API へのアクセス権を制限することがベスト プラクティスとなります。

アクセス スコープはインスタンス単位で適用されます。つまり、インスタンスを作成するときに設定し、インスタンスの存続する間だけ有効になります。

サービス アカウントが属するプロジェクトで関連 API が無効になっている場合、アクセス スコープは適用されません。たとえば、仮想マシン インスタンスに Cloud Storage のアクセス スコープを付与すると、インスタンスはプロジェクトで Cloud Storage API が有効になっている場合にのみ Cloud Storage API を呼び出すことができます。

lab-3 にサービス アカウントがアタッチされていることを確認する

タスク 7. サービス アカウントをテストする

1. gcloud compute ssh を使用して、新規に作成したインスタンスに接続します。SSH セッション内で、以下を実行します。

gcloud compute ssh lab-3 --zone {{{project_1.default_zone_1 | "Zone2"}}}

続行するかどうかを尋ねられたら、Enter キーを押します。

Enter キーを 2 回押して、パスワードの作成をスキップします。

2. 使用されているデフォルトのイメージには、すでに gcloud 構成が含まれています。SSH セッション内で、以下を実行します。

gcloud config list

この構成でサービス アカウントが利用できるようになります。

3. インスタンスを作成します。次のコマンドで、サービス アカウントに必要な権限が付与されていることをテストします。

gcloud compute instances create lab-4 --zone {{{project_1.default_zone_1 | "Zone2"}}} --machine-type=e2-standard-2

Enter キーを押すと、この VM でデフォルトのゾーンが使用されます。

4. アタッチされたロールが機能していることを確認します。SSH セッション内で、以下を実行します。

gcloud compute instances list

サービス アカウントに権限が付与されているため、インスタンスのリストが表示されます。

タスク完了後の環境

お疲れさまでした

このラボでは、Cloud SDK ツール gcloud を使用して以下のタスクを完了しました。

• gcloud クライアントをインストールして構成する
• 複数の IAM 構成を作成し、構成間を切り替える
• 適切な IAM 権限を特定して割り当てる
• サービス アカウントを作成して使用する

次のステップと詳細情報

• Cloud Identity and Access Management に関するドキュメント
• 以下のラボをご確認ください。
  • BigQuery: Qwik Start - コマンドライン
  • gcloud によるネットワークの構成

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2024 年 4 月 10 日

ラボの最終テスト日: 2024 年 4 月 10 日

Copyright 2025 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。