GSP1119

概要

クラウドの専門家がクラウド環境をセットアップする際の最も基本的な懸念事項の一つは、最小権限の原則に従ってリソースへのアクセスをどのように構成するかという点です。主な課題は次のとおりです。

• クラウド環境のリソースへのアクセスを管理する最善の方法とは何か
• どのようにして、ユーザーが実際に必要なリソースに対してのみアクセスを許可するようにできるか
• どのようにして、アプリケーションとサービスがクラウド リソースを認証できるようにするか

このラボでは、Google Cloud における Identity and Access Management（IAM）の基礎について詳しく見ていきます。最小権限の原則を遵守しながら、クラウド リソースへのアクセスを戦略的に構成する方法を学びます。コマンドライン ツールを使用したユーザー権限の管理、必要なアクセス権のみの付与、アプリケーションとサービスに対する安全な認証メカニズムの設定について、重点的に説明します。

Azure IAM に精通している場合は、このラボでこれらのコンセプトを Google Cloud 環境に置き換えて理解することができます。ロールと権限に対する Google Cloud IAM 独自のアプローチについて学びます。このラボでは、gcloud コマンドライン ツールを使用した実際の操作のうち、ツールのインストール、IAM の構成、複数の構成とサービス アカウントの管理を中心として行います。

目標

このラボでは、次の方法について学びます。

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

開始時の環境

2 つのユーザー アカウントと 2 つのプロジェクトを使用して作業を開始します。user1 は両方のプロジェクトの「owner」、user2 は最初のプロジェクトのみの「viewer」です。最初のプロジェクトでは、Linux 仮想マシン（vm）が実行されています。

IAM とは

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

Cloud IAM を使用すると、特定の Google Cloud リソースへのアクセス権をきめ細かく付与し、その他のリソースへの不正なアクセスを防ぐことができます。Cloud IAM では最小権限のセキュリティ原則を導入して、リソースに対する必要なアクセス権のみを付与できます。

ID

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

• Google アカウント
• サービス アカウント
• Google グループ
• G Suite ドメイン
• Cloud Identity ドメイン

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

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

ロール

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

Cloud IAM には、次の 3 種類のロールがあります。

• 基本ロール: Cloud コンソールで以前から使用されているロールは引き続き使用できます。基本ロールには、オーナー、編集者、閲覧者のロールがあります。

• 事前定義済みのロール: 基本のロールより詳細なアクセス制御が可能な Cloud IAM のロールです。たとえば、事前定義済みのロール Pub/Sub パブリッシャー（roles/pubsub.publisher）は、単に Cloud Pub/Sub トピックにメッセージをパブリッシュするだけのアクセス権を提供します。

• カスタムロール: 事前定義ロールがニーズを満たしていない場合に、組織のニーズに応じて権限を調整するために作成するロールです。

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

gcloud とは

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

デフォルトでは、リリースレベルが一般提供とプレビューの gcloud CLI コマンドのみがインストールされます。その他の機能は、SDK コンポーネントの alpha と beta で利用できます。これらのコンポーネントを使用すると、一般提供前のリリースレベルで、Cloud Bigtable、Google Cloud Dataflow、Cloud Platform の他の機能を gcloud CLI を使用して操作できるようになります。

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 をインストールして構成する

最初に、既存の Google Cloud コンピューティング インスタンスに接続し、gcloud SDK をダウンロードおよびインストールし、構成します。

gcloud SDK には、環境の管理を可能にするユーティリティが多数用意されています。まず、ユーティリティにアクションを実行する権限を付与するために認証を構成します。認証プロセスは、使用する ID によって異なります。この例では、ラボで提供された ID（ユーザー アカウント）を使用します。認証が完了したら、環境を構成して、操作するプロジェクトを定義する必要があります。

Cloud SDK ツールの承認について詳しくは、gcloud CLI を承認するをご覧ください。

centos-clean に接続する

このラボには、centos-clean という Compute Engine インスタンスがすでに設定されており、gcloud がインストールされている環境をシミュレートするようになっています。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

4. gcloud 環境の構成を開始します。SSH セッション内で、以下を実行します。

gcloud auth login --no-launch-browser

さまざまなプロンプトが表示されます。

5. [You must log in to continue.] と [Do you want to continue (Y/n)?] が表示されたら、Enter キーを押します。

6. 新しいタブで、プロンプト [Go to the following link in your browser:] の下のリンクに移動します。

このラボの認証情報を使用して、gcloud 環境を認証します。通常は、Compute Engine インスタンスを使用する場合はサービス アカウントを使用します。ここでは自分のワークステーション環境をシミュレートしているため、この提案は無視して続行します。サービス アカウントの使用については、このラボの後半で説明します。

7. リンクをクリックすると、[Google アカウントでログイン] ウェブページが開きます。このラボ用に提供されたアカウントをクリックします（不明な場合は、このページの左上を確認してください）。

8. [許可] をクリックします。

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

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

10. [Pick cloud project to use:] と表示されたら、リストで現在のプロジェクト（ウェブコンソールの最上部にプロジェクト ID が表示されます）を見つけ、プロジェクトの番号を入力して、オプションのリストから選択します。

初期化が完了し、ゾーンとリージョンが設定されます。次のタスクで両方を変更します。

Cloud SDK を初期化する

リージョンとゾーンを設定する

一部の Compute Engine リソースは、リージョン内やゾーン内に存在します。リージョンとは、リソースを実行できる特定の地理的なロケーションです。1 つのリージョンには 1 つ以上のゾーンがあります。

Cloud Shell で次の gcloud コマンドを実行して、ラボのデフォルトのリージョンとゾーンを設定します。

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

gcloud 環境を構成する

gcloud コマンドライン ツールをインストールして基本的な構成を済ませたら、コンピューティング インスタンスを作成して、いくつか変更を加えます。

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

gcloud compute instances create lab-1

2. Enter キーを押すと、この VM でデフォルトのゾーンが使用されます。すべてを正しく設定できていれば、インスタンスが作成されます。

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

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

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

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

gcloud config list

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

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

gcloud compute zones list

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

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

gcloud config set compute/zone ZONE

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

gcloud config list

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

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

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

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

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

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

cat ~/.config/gcloud/configurations/config_default

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

これで、gcloud の構成が完了しました。

タスク 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)?] プロンプトが表示されたら、Enter キーを押します。

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

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

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

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

10. [理解しました] をクリックします。

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

これで、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:] では、現在のプロジェクト（ウェブコンソールの最上部にプロジェクト ID が表示されています）を特定し、そのプロジェクトに対応する番号を入力します。

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

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"}}}

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 人目のユーザーに viewer ロールを割り当てる

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

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

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

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

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

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

gcloud config configurations activate user2

user2 に戻りました。

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

echo "export PROJECTID2={{{project_1.project_id|Project ID 2}}}" >> ~/.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. という警告が返されます。

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

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

3. デフォルトの gcloud 構成に戻します。SSH セッション内で、以下を実行します。

gcloud config configurations activate default

2 人目のユーザーにアクセスを許可する権限を持つ 1 人目のユーザーに切り替える必要があります。

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

5. まず、jq をインストールします。

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

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

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

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

Updated IAM policy for project [qwiklabs-gcp-336e4f5b8aff1c01]. bindings: ... - members: - serviceAccount:qwiklabs-gcp-01-a262cff86157@qwiklabs-gcp-01-a262cff86157.iam.gserviceaccount.com - user:student-01-1b9999e9cc77@qwiklabs.net - user:student-01-c831155b330a@qwiklabs.net 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"}}}

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 [qwiklabs-gcp-336e4f5b8affxxxx]. bindings: - members: - user:gcpstaginguser80_student@qwiklabs.net role: projects/qwiklabs-gcp-336e4f5b8affxxxx/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"}}}

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"}}} --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"}}}

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

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

gcloud compute instances list

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

タスク完了後の環境

お疲れさまでした

Cloud SDK ツール（gcloud）を使用して、gcloud クライアントのインストールと構成、複数の IAM 構成の管理、適切な IAM 権限の割り当て、サービス アカウントの操作を完了しました。これらのタスクは、アクセス制御にコマンドライン ツールを使用する場合の Google Cloud IAM と Azure IAM の類似点を示すものです。どちらのインターフェースでも、アカウント / ロールのプロビジョニング、サービス アカウント / ロールの作成、ユーザーの切り替えを行うことができます。

ロールベース アクセス制御（RBAC）に関して、Azure IAM と Google Cloud IAM には類似点がありますが、違いもあります。ラボで確認した主な違いの一つは、サービス アカウントの作成プロセスです。Google Cloud では、アカウントを登録したり、サービス プリンシパル名を作成したりしません。Google Cloud のプロジェクトは、Azure のテナントのように機能します。gcloud コマンドライン ツールを使用して、複数のプロジェクトにわたってアカウントをプロビジョニングしました。これは、Azure CLI を使用して複数のテナントにわたってアクセスをプロビジョニングする方法と似ています。

次のステップと詳細情報

• Cloud Identity and Access Management のドキュメントをご確認ください

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

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

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

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

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