このページでは、 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）と組織のポリシーにとっての論理的な接続ポイントを提供します。許可ポリシー、拒否ポリシー、組織のポリシーは階層から継承されます。階層内の各リソースで有効なポリシーは、リソースに直接適用されるポリシーと、祖先から継承されたポリシーを組み合わせたものになります。
次の図は、 Google Cloud リソース階層の例を示しています。
組織リソース
組織リソースは、組織（会社など）を表し、これはGoogle Cloud リソース階層（ある場合）のルートノードです。組織リソースは、階層上、フォルダとプロジェクト リソースの祖先になります。組織リソースに適用される許可ポリシーと拒否ポリシーは、組織内のすべてのリソースの階層全体に適用されます。
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"
}
}
新しく作成された組織リソース用の最初の許可ポリシーは、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 ロールは、そのフォルダ内のすべてのプロジェクト リソースとフォルダ リソースに自動的に継承されます。
プロジェクト リソース
プロジェクト リソースは、基本レベルの構成エンティティです。組織リソースとフォルダ リソースには、複数のプロジェクトを含めることができます。 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 ポリシーは、プロジェクト作成者にオーナーのロールを付与します。
許可ポリシーと拒否ポリシーの継承
Google Cloud には IAM 機能があります。これにより、特定の Google Cloud リソースに対するアクセス権を詳細に設定できるため、他のリソースへの不正なアクセスを防ぐことができます。IAM では、リソースに対して許可ポリシーと拒否ポリシーを設定することで、誰（ユーザー）がどのようなアクセス権（ロール）をどのリソースに対して持つのかを制御できます。
組織リソース、フォルダ リソース、プロジェクト リソースに対して、許可ポリシーと拒否ポリシーを設定できます。一部のサービス リソースに許可ポリシーを設定することもできます。
リソースは親リソースのポリシーを継承します。組織レベルで許可ポリシーまたは拒否ポリシーを設定すると、すべての子リソースに継承されます。プロジェクト レベルで許可ポリシーを設定すると、そのすべての子リソースにポリシーが継承されます。
リソースで有効な許可ポリシーまたは拒否ポリシーは、そのリソースに設定された許可ポリシーまたは拒否ポリシーと、親リソースから継承された許可ポリシーまたは拒否ポリシーを組み合わせたものです。この継承は、過渡的に行われます。詳細については、ポリシー評価をご覧ください。
たとえば、前述のリソース階層図で、Compute Engine インスタンス管理者（roles/compute.instanceAdmin）ロールを bob@example.com に付与する許可ポリシーを「Department Y」フォルダに設定すると、Bob は「Development project」、「Test project」、「Production project」でそのロールを取得します。「Test project」の Compute Engine インスタンス管理者のロールを alice@example.com に割り当てると、Alice はそのプロジェクトの Compute Engine インスタンスのみを管理できます。
ロールは常に継承されます。「Test project」の Bob から Compute Engine インスタンス管理者（roles/compute.instanceAdmin）ロールを削除しても、Bob は「Department Y」フォルダからそのロールを継承します。拒否ポリシーを使用すると、プリンシパルが継承された権限を使用できないようにできます。
許可ポリシーと拒否ポリシーは、 Google Cloud リソース階層を介して継承されます。リソース階層を変更すると、許可ポリシーと拒否ポリシーの階層も変更されます。たとえば、プロジェクトを組織リソースに移動すると、そのプロジェクトの許可ポリシーと拒否ポリシーは、その組織リソースの許可ポリシーと拒否ポリシーから継承するように更新されます。同様に、プロジェクト リソースをフォルダ リソース間で移動すると、継承された権限が変更されます。プロジェクト リソースを新しいフォルダに移動すると、元の親リソースのプロジェクト リソースから継承された権限が失われます。移動先フォルダ リソースで設定される権限は、移動時にプロジェクト リソースから継承されます。
使ってみる
Google Cloudを初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
無料で開始