リソース階層

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

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

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

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

Google Cloud リソース階層の詳細

Google Cloud のリソースは階層的に編成されます。階層内の最上位のリソースを除くすべてのリソースの親は 1 つだけです。最下位レベルでは、サービス リソースはすべての Google Cloud サービスを構成する基本コンポーネントです。サービス リソースの例としては、Compute Engine 仮想マシン(VM)、Pub/Sub トピック、Cloud Storage バケット、App Engine インスタンスなどがあります。これらの下位レベルのリソースには、プロジェクト リソースが親リソースとして割り当てられています。これは、Google Cloud リソース階層の最初のグループ化メカニズムです。

無料トライアル ユーザー、無料枠ユーザー、Google Workspace または Cloud Identity のお客様など、すべてのユーザーがプロジェクト リソースを作成できます。Google Cloud の無料プログラムのユーザーは、プロジェクト内でのみリソースとプロジェクト リソースを作成できます。プロジェクト リソースは階層の最上位にすることができますが、無料試用ユーザーまたは無料枠ユーザーによって作成された場合に限ります。Google Workspace と Cloud Identity のお客様は、組織リソースやフォルダ リソースなど、Google Cloud リソース階層の追加機能を利用できます。詳細については、Cloud Identity の概要をご覧ください。階層の最上位のプロジェクト リソースには親リソースがありませんが、組織リソースを作成した後に組織リソースに移行できます。プロジェクト リソースの移行の詳細については、プロジェクト リソースの移行をご覧ください。

Google Workspace と Cloud Identity のお客様は、組織リソースを作成できます。各 Google Workspace アカウントまたは Cloud Identity アカウントは、1 つの組織リソースに関連付けられます。組織リソースが存在する場合、それは Google Cloud リソース階層の最上位にあり、組織に属するすべてのリソースは組織リソースの下にグループ化されます。これにより、組織に属するすべてのリソースを集中管理できます。

フォルダ リソースは、組織リソースとプロジェクト リソース間の追加のグループ化メカニズムです。フォルダは、前提条件として組織リソースが必要です。フォルダ リソースと子プロジェクト リソースは、組織リソースにマッピングされます。

Google Cloud リソース階層は、組織リソースとフォルダ リソースを含む最も完全な形式で、組織を Google Cloud にマッピングし、アクセス管理ポリシー(IAM)と組織のポリシーの論理的な接続ポイントを提供します。IAM と組織のポリシーはともに階層から継承されます。階層内の各リソースで有効なポリシーは、リソースに直接適用されたポリシーと、祖先から継承されたポリシーです。

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

組織リソース

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

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

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 ドメイン全体にプロジェクト作成者と請求先アカウント作成者のロールを付与します。つまり、ユーザーは、組織リソースが存在する前と同じように、プロジェクト リソースと請求先アカウントの作成を続行できます。組織リソースの作成時に、他のリソースは作成されません。

フォルダ リソース

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

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

フォルダ リソースを使用すると、管理権限を委任できます。たとえば、部門の各責任者にその部門のすべての Google Cloud リソースに対する完全な所有権を付与できます。同様に、フォルダリソースによってリソースに対するアクセス権を制限できます。したがって、ある部門のユーザーは、その部門のフォルダ リソース内の Google 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 コンソールのプロジェクト リソースのダッシュボードにあります。プロジェクト ID とプロジェクト リソースのその他の管理タスクを取得する方法については、プロジェクト リソースの作成と管理をご覧ください。

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

IAM ポリシーの継承

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

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

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

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

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

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

使ってみる

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

無料で開始