このページでは、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 プロジェクトを作成すると、組織リソースが自動的にプロビジョニングされます。
1 つの Google Workspace または Cloud Identity アカウントには、1 つの組織リソースがプロビジョニングされます。ドメインに組織リソースを作成すると、アカウント ドメインのメンバーが作成する新しい Google Cloud プロジェクト リソースはデフォルトで組織リソースに属するようになります。管理対象ユーザーがプロジェクト リソースを作成する場合、そのプロジェクトは、いずれかの組織リソースに存在する必要があります。ユーザーが組織リソースを指定し、適切な権限を持っている場合、プロジェクトはその組織に割り当てられます。それ以外の場合は、ユーザーが関連付けられている組織リソースがデフォルトになります。組織リソースに関連付けられているアカウントが、組織リソースに関連付けられていないプロジェクト リソースを作成することはできません。
Google Workspace アカウントまたは Cloud Identity アカウントとのリンク
説明を簡単にするために、ここでは「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 で組織リソースのライフサイクルに従います。
また、組織管理者はすべてのリソースを集中的に管理できます。会社のプロジェクト リソースをすべて表示、管理できます。これにより、隠れたプロジェクトや不正な管理者が存在しなくなります。
また、組織レベルでロールを付与すると、組織リソースの下にあるすべてのプロジェクト リソースとフォルダ リソースに継承されます。たとえば、組織レベルでネットワーク管理者のロールをネットワーク チームに付与することで、個別のプロジェクト リソースすべてに対するロールを付与する代わりに、会社内のすべてのプロジェクト リソースに含まれるすべてのネットワークをこのネットワーク チームが管理できるようになります。
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 コンソールにリソースが表示されます。詳細については、フォルダとプロジェクト リソースの表示または一覧表示をご覧ください。
フォルダ リソースを使用すると、管理権限を委任できます。たとえば、部門の各責任者にその部門のすべての 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 つの識別子:
- プロジェクト リソース ID。これはプロジェクト リソースの一意の識別子です。
- プロジェクト リソース番号。プロジェクトを作成するときに自動的に割り当てられた番号です。これは読み取り専用です。
- 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 またはプロジェクト リソース番号（コード スニペットの projectId と projectNumber）のいずれかで識別できます。
プロジェクト リソース ID は、プロジェクト リソースの作成時に選択したカスタマイズされた名前です。プロジェクト リソースが必要な API を有効にすると、プロジェクト リソースを作成するか、プロジェクト リソース ID を使用してプロジェクト リソースを選択するように指示されます（UI に表示される name 文字列はプロジェクト ID と同じではありません）。
プロジェクト番号は Google Cloud によって自動的に生成されます。プロジェクト リソース ID とプロジェクト リソース番号は、Google Cloud コンソールのプロジェクト リソースのダッシュボードで確認できます。プロジェクト識別子の取得方法やプロジェクト リソースの他の管理タスクの詳細については、プロジェクト リソースの作成と管理をご覧ください。
新しく作成されたプロジェクト リソース用の最初の 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 分を差し上げます。
無料で開始