デフォルトでは、すべての Google Cloud プロジェクトに単一のユーザー（元のプロジェクト作成者）が設定されています。その他のユーザーはプロジェクト メンバーとして追加されるか、特定のリソースにバインディングされるまで、そのプロジェクトにアクセスできず、Compute Engine リソースにもアクセスできません。このページでは、プロジェクトに新しいユーザーを追加する方法と、Identity and Access Management（IAM）を使用して Compute Engine リソースに対するアクセス制御を設定する方法について説明します。
Compute Engine インスタンスで実行されているアプリケーションへのアクセスを提供する方法については、承認の判断方法をご覧ください。
ユーザーのアクセス制御オプション
ユーザーが Compute Engine リソースを作成して管理できるようにするには、ユーザーをプロジェクトまたは特定のリソースにチームメンバーとして追加し、IAM ロールを使用して権限を付与します。
チームメンバーにできるのは、有効な Google アカウント、Google グループ、サービス アカウント、Google Workspace のドメインのいずれかを持つ個別のユーザーです。プロジェクトまたはリソースにチームメンバーを追加するときは、そのメンバーに付与するロールを指定します。IAM には、事前定義ロール、基本ロール、カスタムロールの 3 種類のロールがあります。
リソースは Google Cloud のリソース階層での親リソースのポリシーを継承します。リソースで有効なポリシーは、そのリソースに設定されたポリシーとその親リソースから継承されたポリシーを組み合わせたものです。
Compute Engine の事前定義ロール
事前定義された役割は、関連する一連の権限を付与します。Compute Engine には、以下の事前定義された役割が用意されています。
| ロールのタイトル | 機能 | ターゲット ユーザー |
|---|---|---|
| Compute Engine イメージ ユーザー |
別のプロジェクトのイメージを一覧表示して使用する権限。メンバーにこの役割を別の役割と一緒に付与すると、メンバーは別のプロジェクトのイメージを使用して新しいリソースを作成できるようになります。たとえば、このロールとインスタンス管理者のロールを付与すると、メンバーは別のプロジェクトのイメージを使用して VM インスタンスと永続ディスクを作成できるようになります。 マネージド インスタンス グループを作成しているか、Deployment Manager を使用して VM インスタンスを作成する場合に、他のプロジェクトのイメージを使用するには、その前にプロジェクトの Google API サービス アカウントにこのロールを付与する必要がある場合があります。 |
|
| Compute Engine インスタンス管理者（v1） |
Compute Engine インスタンス、インスタンス グループ、ディスク、スナップショット、イメージのすべてを管理する権限。すべての Compute Engine ネットワーキング リソースへの読み取り専用アクセス権。 メンバーが、サービス アカウントとして実行されるように構成されている VM インスタンスを管理している場合は、メンバーが VM インスタンスにサービス アカウントを割り当てることができるように、 |
|
| Compute Engine 管理者の役割 |
Compute Engine リソースのすべてを管理できる権限。ユーザーがサービス アカウントとして実行するように構成されている VM インスタンスを管理している場合は、 |
|
| Compute Engine ネットワーク管理者 |
ネットワーキング リソース（ファイアウォール ルールと SSL 証明書を除く）を作成、変更、削除するための権限。ネットワーク管理者の役割により、ファイアウォール ルール、SSL 証明書、インスタンス（それぞれのエフェメラル IP アドレスの表示用）への読み取り専用アクセスを付与できます。メンバーは、ネットワーク管理者の役割では、インスタンスの作成、起動、停止、削除はできません。 |
ネットワーク管理者 |
| Compute Engine セキュリティ管理者 |
ファイアウォール ルールと SSL 証明書を作成、変更、削除するための権限。 |
セキュリティ管理者 |
| Compute Engine ロードバランサ管理者ベータ版 |
ロードバランサと関連リソースを作成、変更、削除する権限。 |
ロードバランサ管理者 |
| Compute Engine サービス アカウントのユーザー |
サービス アカウントを使用するインスタンスの作成権限、およびディスクを接続して、サービス アカウントとして実行するようにすでに構成されているインスタンスにメタデータを設定する権限。 このロールには Compute Engine API にアクセスする権限がないため、このロールを単独では付与しないでください。このロールと別のロール（インスタンス管理者のロールなど）をメンバーに付与してください。 |
|
| Compute Engine 閲覧者の役割 |
Compute Engine リソースを取得して表示するための読み取り専用アクセス権。そこに格納されたデータを読み取ることはできません。たとえば、この役割を持つアカウントはプロジェクトのすべてのディスクの一覧を作成できますが、それらのディスク内のデータは読み取ることができません。 |
システム管理者 |
| Compute Engine ネットワーク ユーザー |
共有 VPC ネットワークを使用する権限。具体的には、ホスト プロジェクトでリソースを使用する必要があるサービス オーナーにこの役割を付与します。アクセス権を付与されたサービス オーナーは、ホスト プロジェクトに属するサブネットワークとネットワークを使用できます。たとえば、ネットワーク ユーザーは、共有 VPC ホスト ネットワークに属する VM インスタンスを作成できますが、ホスト プロジェクトでネットワークを削除したり、新しいネットワークを追加したりすることはできません。 |
|
| Compute Engine ネットワーク閲覧者 |
すべてのネットワーク リソースへの読み取り専用アクセス権。たとえば、ネットワーク構成を検査するソフトウェアがある場合は、そのソフトウェアのサービス アカウントにネットワーク閲覧者の役割を付与します。 |
|
| Compute Engine ストレージ管理者ベータ版 |
ディスク、イメージ、スナップショットを作成、変更、削除するための権限。 たとえば、イメージを管理しているメンバーが社内にいて、プロジェクトに対する編集者の役割を付与したくない場合は、各メンバーのアカウントにこの役割を付与します。 |
|
| Compute Engine 共有 VPC 管理者 |
共有 VPC ホスト プロジェクトを管理する権限。特にホスト プロジェクトを有効にし、サービス プロジェクトをホスト プロジェクトのネットワークに関連付ける権限。この役割は、組織レベルでのみ付与できます。 |
プロジェクト作成者 |
特定のロールが権限を付与する API メソッドのリストを確認するには、Compute Engine IAM のロールのドキュメントをご覧ください。
事前定義ロールのマトリックス
次の表に、Compute Engine のロールごとに可能な操作の比較を示します。
| 機能 | インスタンス管理者（v1） | イメージ ユーザー | ネットワーク ユーザー | ネットワーク閲覧者 | ネットワーク管理者 | セキュリティ管理者 | ストレージ管理者 | 共有 VPC 管理者 | Compute 管理者 | Compute 閲覧者 | ロードバランサ管理者 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| VM インスタンスの作成または削除 | * | ||||||||||
| VM インスタンスへの SSH 接続 | * | * | |||||||||
| VM インスタンスの一覧表示または取得 | |||||||||||
| イメージ、ディスク、スナップショットの作成または削除 | |||||||||||
| イメージの一覧表示または取得 | |||||||||||
| インスタンス グループの作成または削除 | * | ||||||||||
| インスタンス グループの一覧表示または取得 | |||||||||||
| ロードバランサの作成と管理 | |||||||||||
| VPN の作成と管理 | |||||||||||
| ネットワーク / サブネットワークのリソースの表示 | |||||||||||
| ファイアウォール ルールの表示 | |||||||||||
| ファイアウォールと SSL 証明書の作成と管理 |
ファイアウォール、 SSL 証明書 |
||||||||||
| 共有 VPC ホスト プロジェクトの作成と管理 | |||||||||||
| 共有 VPC ホスト プロジェクトでのネットワークとサブネットワークの使用 | |||||||||||
| ネットワークとサブネットワークの作成と管理 |
* VM インスタンスをサービス アカウントとして実行できる場合は、サービス アカウント ユーザーのロールも付与してください。
特定のロールが権限を付与する API メソッドのリストを確認するには、Compute Engine IAM のロールのドキュメントをご覧ください。
IAM の基本ロール
IAM の基本ロールは、従来のプロジェクト オーナー、編集者、閲覧者の各ロールに直接対応付けられています。通常は、可能な限り事前定義ロールを使用する必要があります。ただし、IAM がまだサポートされていない一部のケースでは、正しい権限を付与するために、基本ロールを使用する必要があります。
| ロールのタイトル | 権限 |
|---|---|
Owner |
すべての閲覧者権限と編集者権限に加え、課金設定の変更、アクセス制御の管理、プロジェクトの削除が可能。 |
Editor |
すべての閲覧者権限に加え、リソースの作成、変更、削除が可能。 |
Viewer |
すべてのリソースに対する読み取り専用権限。リソースを変更する権限はありません。 |
基本ロールの詳細については、基本ロールのドキュメントをご覧ください。
事前定義ロールや基本ロールがニーズに合わない場合は、カスタムロールを作成できます。
Compute Engine リソースの IAM ポリシー
VM インスタンス、イメージ、ディスクなどの Compute Engine リソースへのアクセス権を付与するには、これらのリソースに直接 IAM ポリシーを接続します。IAM ポリシーを使用すると、プロジェクト レベルでロールを管理する代わりに、これらのリソースの IAM ロールを管理できます。これにより、共同編集者が作業を行うために必要な特定のリソースのみへのアクセスを許可する、最小権限の原則を適用できます。
Compute Engine リソースの IAM ポリシーを使用すると、次のことができます。
- ユーザーにリソースの特定のサブセットへのアクセスを許可します。Alice がプロジェクト内の一部のインスタンスを管理する必要があるとします。この場合、インスタンス レベルの IAM ポリシーを使用して、対象のインスタンスに限定した
compute.instanceAdmin.v1のロールを Alice に付与します。同じロールをプロジェクトで Alice に付与した場合は、プロジェクト内のすべてのインスタンスを変更する権限が付与されることになります。 - アクセスの付与を管理者に許可します。強い権限を持つプロジェクト オーナーでなくても、管理者がインスタンス、ディスク、イメージに対するアクセスを他のユーザーに付与できるようにします。Bob が特定のイメージに対する
compute.storageAdminの役割を付与されているデベロッパーであるとします。Bob は、そのイメージに対するcompute.imageUserのロールをチームメートに付与することにより、そのメンバーとイメージを共有できます。Compute Engine リソースの IAM ポリシーを使用しない場合、チームメートとそのイメージを共有するにはプロジェクトのポリシーを変更する必要があるため、Bob は IAM のプロジェクト オーナーでない限りイメージを共有できません。
リソースは親リソースのポリシーも継承します。プロジェクト レベルでポリシーを設定すると、そのすべての子リソースでそのポリシーが継承されます。特定のリソースに対して有効なポリシーは、そのリソースに設定されたポリシーとリソース階層の上位から継承されるポリシーを組み合わせたものです。詳細については、IAM ポリシーの階層をご覧ください。
組織のポリシー
Google Workspace のメンバーの場合、プロジェクトが組織リソースの一部になっている可能性があります。組織リソースは、Google Workspace アカウントと緊密に連携している Google Cloud リソース階層のスーパーノードです。Google Workspace ドメインに組織リソースを作成すると、ドメインのメンバーが作成するすべての Google Cloud プロジェクトが組織リソースに属するようになります。
組織では、Google Cloud リソース階層全体で許可する構成を制限するポリシーである組織のポリシーを実装できます。Compute Engine の場合は、次のポリシーを実装できます。
組織のポリシーを設定するには、組織での orgpolicy.policyAdmin のロールが付与されている必要があります。ポリシーに対する例外がある場合は、プロジェクト固有のオーバーライドを設定することもできます。
組織について詳しくは、組織のドキュメントをご覧ください。
組織のポリシーについて詳しくは、組織のポリシーのドキュメントをご覧ください。
ユーザーに VM インスタンスへの SSH アクセスを許可する
ユーザーに Compute Engine リソースの管理権限を付与せずに、SSH を使用した VM インスタンスへの接続を許可するには、プロジェクトにユーザーの公開鍵を追加するか、特定のインスタンスにユーザーの公開鍵を追加します。この方法を使用すると、ユーザーをプロジェクト メンバーとして追加しなくても、特定のインスタンスへのアクセスを許可できるようになります。
SSH および SSH 認証鍵の管理について詳しくは、SSH 認証鍵の概要をご覧ください。
プロジェクト メンバーに roles/compute.instanceAdmin.v1 の役割を付与した場合は、インスタンスがサービス アカウントとして実行するように設定されていない限り、メンバーは自動的に SSH を使用してインスタンスに接続できます。インスタンスがサービス アカウントとして実行するように設定されている場合に、メンバーがそのインスタンスに接続するには、事前に roles/iam.serviceAccountUser の役割も付与する必要があります。
メンバーをプロジェクトのオーナーまたは編集者として追加すると、プロジェクト内の VM インスタンスへの SSH アクセスも自動的に付与されます。
VM インスタンスで実行されるアプリのアクセス制御
インスタンスでアプリのコードを実行しており、そのアプリが他の Google Cloud APIs に対して認証を行う必要がある場合は、サービス アカウントを作成し、他の Google Cloud APIs に対して代理で認証を行う特定の IAM ロールをそのサービス アカウントに付与できます。サービス アカウントは、ユーザーの認証情報を備えていない、サーバー間のやり取りに最適な特別アカウントです。
サービス アカウントについて詳しくは、サービス アカウントのドキュメントをご覧ください。
Compute Engine ワークロードのマネージド ワークロード ID
マネージド ワークロード ID を使用して、Certificate Authority Service（CA Service）からの X.509 証明書の自動プロビジョニングとライフサイクル管理を設定できます。マネージド ワークロード ID 証明書は CA Service から発行されます。CA Service は、可用性が高くスケーラブルな Google Cloud サービスで、CA サービスのデプロイ、管理、セキュリティの簡素化と自動化に役立ちます。秘密鍵は自分で管理できます。
マネージド ワークロード ID を使用すると、Compute Engine によって管理される VM ごとの mTLS を利用できます。VM ごとの mTLS は、VM の作成時に発行された X.509 証明書を使用します。これらの mTLS 証明書は自動的にローテーションされるため、証明書の管理について心配する必要はありません。
マネージド ワークロード ID は、任意の 2 つの Compute Engine VM 間で相互認証を行い、暗号化された通信を確立するための基盤となります。たとえば、マネージド ワークロード ID を使用する場合、ある VM で実行されているサービス A が、mTLS を使用して確立された暗号化されたチャネルを介して、別の VM で実行されているサービス B と通信します。
マネージド ワークロード ID の構成については、mTLS を使用してワークロード間で認証を行うをご覧ください。
次のステップ
- ユーザーをチームメンバーとして追加する。
- IAM のロールの詳細を確認する。
- SSH 認証鍵の追加と削除の詳細を確認する。
- サービス アカウントの詳細を確認する。