リソース階層

このページでは、Google Cloud のリソース階層と、Resource Manager を使用して管理できるリソースについて説明します。

Google Cloud のリソース階層の目的は次の 2 つです。

  • 所有権を階層的に編成し、リソースのライフサイクルを階層で直接の親にバインドする。
  • アクセス制御ポリシーと組織のポリシーの接続ポイントを提供し、継承を可能にする。

Google Cloud のリソース階層は、エンティティを階層的に編成して管理している点では、従来のオペレーティング システムのファイル システムに類似しています。各リソースの親は 1 つだけです。リソースを階層的に編成することで、親リソースにアクセス制御ポリシーと構成設定を割り当て、ポリシーと Identity and Access Management(IAM)設定を子リソースに継承できます。

Google Cloud リソース階層の詳細

最下位レベルでは、リソースが Google Cloud サービスを構成する基本要素となります。リソースの例には、Compute Engine 仮想マシン(VM)、Pub/Sub トピック、Cloud Storage バケット、App Engine インスタンスなどがあります。個々の下位レベルのリソースの親となるのは、プロジェクトのみです。プロジェクトは、Google Cloud のリソース階層の最初のグループ化メカニズムとなります。

Google Workspace と Cloud Identity のお客様は、Google Cloud のリソース階層の他の機能にアクセスでき、集中管理や制御などのメリットと、フォルダなどの追加のグループ化メカニズムを得られます。詳しくは、Cloud Identity の概要をご覧ください。

Google Cloud のリソースは階層的に編成されます。階層の下からみると、プロジェクトが最初のレベルとなり、その中に他のリソースが存在します。組織を除けば、すべてのリソースには必ず 1 つの親があります。組織は、階層の最上位に存在するため、親はありません。

組織リソースは Google Cloud リソース階層のルートノードであり、組織に属するすべてのリソースは組織ノードの下にグループ化されます。これにより、組織に属するすべてのリソースを集中管理できます。

フォルダは、プロジェクトの上位にあるグループ化メカニズムです。フォルダを使用するには、前提条件として組織リソースが必要です。フォルダとプロジェクトはすべて組織リソースにマッピングされます。

完全な Google Cloud リソース階層には組織のリソースとフォルダが含まれています。この階層により、組織を Google Cloud にマッピングし、アクセス管理ポリシー(IAM)と組織のポリシーを論理的に接続できます。IAM と組織ポリシーはともに階層から継承されます。階層の各ノードで有効なポリシーは、ノードに直接適用されるポリシーで、祖先から継承されます。

次の図は、Google Cloud リソース階層の完全な形態の例です。

組織リソース

組織リソースは、組織(会社など)を表し、Google Cloud リソース階層のルートノードです。組織リソースは、階層上、プロジェクト リソースとフォルダの祖先になります。組織リソースに適用される IAM アクセス制御ポリシーは、組織のすべてのリソースの階層全体に適用されます。

GCP ユーザーは組織リソースを持っている必要はありませんが、それがないと一部の Resource Manager 機能を使用できません。組織リソースは、Google Workspace または Cloud Identity アカウントと密接に関連しています。Google Workspace または Cloud Identity アカウントを持つユーザーが Google Cloud プロジェクトを作成すると、それらのユーザーに組織リソースが自動的にプロビジョニングされます。

1 つの Google Workspace または Cloud Identity アカウントには、1 つの組織がプロビジョニングされます。ドメインに組織リソースを作成すると、アカウント ドメインのメンバーが作成するすべての Google Cloud プロジェクトはデフォルトで組織リソースに属するようになります。管理対象ユーザーがプロジェクトを作成する場合、そのプロジェクトは、いずれかの組織内に存在する必要があります。ユーザーが組織を指定し、適切な権限を持っている場合、プロジェクトはその組織に割り当てられます。それ以外の場合は、ユーザーが関連付けられている組織がデフォルトになります。組織に関連付けられていないプロジェクトを作成することはできません。

説明を簡単にするために、ここでは「Google Workspace」を Google Workspace ユーザーと Cloud Identity ユーザーの両方の意味で使用します。

Google Workspace または Cloud Identity アカウントは会社を表し、組織リソースにアクセスするための前提条件です。Google Cloud のコンテキストでは、ID 管理、復旧、所有権、ライフサイクルの管理を行います。次の図は、Google Workspace アカウント、Cloud Identity、Google Cloud リソース階層の関係を示しています。


Google Workspace 特権管理者はドメインの所有権を確認する責任者で、復旧時の連絡窓口となります。このため、Google Workspace 特権管理者にはデフォルトで IAM ロールの割り当て権限が付与されます。Google Cloud に関連する Google Workspace 特権管理者の主なロールは、組織管理者の IAM ロールをドメイン内の適切なユーザーに割り当てることです。これにより、ユーザーが一般的に求めている Google Workspace と Google Cloud の管理責任の分離がなされます。

組織リソースのメリット

組織リソースを使用すると、プロジェクトはそれを作成した従業員ではなく、組織に属します。つまり、従業員が離職してもプロジェクトは削除されず、Google Cloud 上で組織のライフサイクルに従うことになります。

また、組織管理者はすべてのリソースを集中的に管理できます。会社のプロジェクトをすべて表示し、管理できます。これにより、隠れたプロジェクトや不正な管理者が存在しなくなります。

組織レベルでロールを付与すると、組織リソースの下にあるすべてのプロジェクトとフォルダに継承されます。たとえば、組織レベルでネットワーク管理者のロールをネットワーク チームに付与することで、個別のプロジェクトすべてに対するロールを付与する代わりに、会社内のすべてのプロジェクトに含まれるすべてのネットワークをこのネットワーク チームが管理できるようになります。

Resource Manager API によって公開される組織リソースは、以下から構成されています。

  • 組織を一意に表す識別子である組織 ID。
  • 表示名。Google Workspace または Cloud Identity のプライマリ ドメイン名から生成されます。
  • 組織の作成時刻。
  • 組織の最終更新時刻。
  • 組織のオーナー。オーナーは組織リソースを作成するときに指定されます。いったん設定したら変更できません。これは、Directory API で指定された Google Workspace のお客様 ID です。

次のコード スニペットは、組織リソースの構造を示します。

{
  "creationTime": "2020-01-07T21:59:43.314Z",
  "displayName": "my-organization",
  "lifecycleState": "ACTIVE",
  "name": "organizations/34739118321",
  "owner": {
    "directoryCustomerId": "C012ba234"
  }
}

新しく作成された組織リソース用の最初の IAM ポリシーは、Google Workspace ドメインの全体に Project Creator ロールと Billing Account Creator ロールを付与します。これにより、ユーザーは組織の存在前と同様にプロジェクトと請求先アカウントを作成できます。組織リソースの作成時には、他のリソースは作成されません。

フォルダ リソース

フォルダ リソースを使用すると、プロジェクトをグループ化し、プロジェクトを分離することができます。組織内ではサブ組織としてみることができます。フォルダ、異なる法人、部門、社内チームのモデル化に使用できます。たとえば、最初のレベルのフォルダで、組織の主要部門を表すことができます。フォルダ内にはプロジェクトや他のフォルダを作成できるので、サブフォルダで他のチームを表すことができます。さらに、各チームのフォルダにサブフォルダを追加し、アプリケーションを表すことができます。フォルダの使い方については、フォルダの作成と管理をご覧ください。

フォルダ リソースが組織内に存在し、適切な表示権限がある場合は、Google Cloud Console にリソースが表示されます。詳細については、フォルダとプロジェクトを表示または一覧表示するをご覧ください。

フォルダを使用すると、管理権限を委譲できます。たとえば、部門の責任者にその部門のすべての Google Cloud リソースに対する完全な所有権を付与できます。同様に、フォルダによってリソースに対するアクセス権を制限できます。これにより、1 つの部門のユーザーにそのフォルダ内の Cloud リソースにのみアクセスと作成を許可できます。

次のコード スニペットはフォルダの構造を示します。

{
  "createTime": "2030-01-07T21:59:43.314Z",
  "displayName": "Engineering",
  "lifecycleState": "ACTIVE",
  "name": "folders/634792535758",
  "parent": "organizations/34739118321"
}

組織やプロジェクトと同様に、フォルダは IAM や組織ポリシーの継承ポイントとして機能します。フォルダに付与された IAM ロールは、そのフォルダ内のすべてのプロジェクトとフォルダに自動的に継承されます。

プロジェクト リソース

プロジェクト リソースは、基本レベルの構成エンティティです。組織とフォルダには複数のプロジェクトを含めることができます。Google Cloud を使用するにはプロジェクトが必要で、すべての Google Cloud サービスの作成、有効化、使用、API の管理、課金の有効化、共同編集者の追加と削除、権限の管理などの基礎となります。

プロジェクトは、次のものから構成されます。

  • 2 つの識別子:
    1. プロジェクトの一意の識別子であるプロジェクト ID。
    2. プロジェクトを作成するときに自動的に割り当てられたプロジェクト番号。これは読み取り専用です。
  • 1 つの変更可能な表示名
  • プロジェクトのライフサイクルの状態。例: ACTIVE、DELETE_REQUESTED。
  • プロジェクトのフィルタリングに使用できるラベルのコレクション。
  • プロジェクトが作成された時刻。

次のコード スニペットはプロジェクトの構造を示します。

{
  "createTime": "2020-01-07T21:59:43.314Z",
  "lifecycleState": "ACTIVE",
  "name": "my-project",
  "parent": {
    "id": "634792535758",
    "type": "folder"
  },
  "projectId": "my-project",
  "labels": {
     "my-label": "prod"
  },
  "projectNumber": "464036093014"
}

Google Cloud リソースを操作するときには、ほとんどの場合リクエストごとにプロジェクト識別情報を提供する必要があります。プロジェクトは、プロジェクト ID またはプロジェクト番号(コード スニペットの projectIdprojectNumber)のいずれかで識別できます。

プロジェクト ID は、プロジェクトの作成時に選択したカスタマイズされた名前です。プロジェクトが必要な API を有効にすると、プロジェクトを作成するか、プロジェクト ID を使用してプロジェクトを選択するように指示されます(UI に表示される name 文字列はプロジェクト ID と同じではありません)。

プロジェクト番号は Google Cloud によって自動的に生成されます。プロジェクト ID とプロジェクト番号はいずれも、Google Cloud Console のプロジェクトのダッシュボードにあります。プロジェクト識別子の取得方法やプロジェクトの他の管理タスクの詳細については、プロジェクトの作成と管理をご覧ください。

新しく作成されたプロジェクト リソース用の最初の IAM ポリシーは、プロジェクト作成者にオーナーのロールを付与します。

IAM ポリシーの継承

Google Cloud には IAM 機能があります。これにより、特定の Google Cloud リソースに対するアクセス権を詳細に設定できるため、他のリソースへの不正なアクセスを防ぐことができます。IAM は、リソースに対して IAM ポリシーを設定することで、誰(ユーザー)がどのようなアクセス権(ロール)をどのリソースに対して持つのかを制御できるようにします。

IAM ポリシーは組織レベルフォルダレベルプロジェクト レベル、あるいは(場合によっては)リソースレベルで設定できます。リソースでは親ノードのポリシーが継承されます。組織レベルで設定されたポリシーはすべての子フォルダとプロジェクトに継承され、プロジェクト レベルで設定されたポリシーはすべての子リソースに継承されます。

リソースで有効なポリシーは、そのリソースに設定されたポリシーとその親リソースから継承されたポリシーの和です。この継承は、過渡的に行われます。つまり、リソースは、組織からポリシーを継承したプロジェクトからポリシーを継承します。したがって、組織レベルのポリシーはリソースレベルでも適用されます。

たとえば、上のリソース階層図で、プロジェクト編集者のロールを bob@gmail.com に付与するポリシーを「Dept Y」フォルダに設定すると、「Dev GCP Project」、「Test GCP Project」、「Production GCP Project」プロジェクトの編集者のロールが Bob に付与されます。逆に、プロジェクト「Test GCP Project」のインスタンス管理者のロールを alice@example.com に付与すると、Alice には、そのプロジェクトの Compute Engine インスタンスの管理のみが許可されます。

ロールは常に継承されるため、リソース階層の上位レベルで付与されている下位レベルのリソースに対する権限を明示的に削除する手段はありません。上記の例では、Bob から「Test GCP Project」に対するプロジェクト編集者のロールを削除しても、Bob は依然として「Dept Y」フォルダからそのロールを継承するため、引き続き「Test GCP Project」に対するそのロールの権限を保持します。

IAM ポリシー階層は、Google Cloud リソース階層と同じパスをたどります。リソース階層を変更すると、ポリシー階層も変更されます。たとえば、プロジェクトを組織に移動すると、そのプロジェクトの IAM ポリシーは、その組織の IAM ポリシーから継承するように更新されます。同様に、フォルダ間でプロジェクトを移動すると、継承された権限が変更されます。プロジェクトを新しいフォルダに移動すると、元の親から継承された権限が失われます。移動先で設定される権限は、移動時にプロジェクトから継承されます。

使ってみる

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

無料で開始