リソース階層

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

GCP のリソース階層には 2 つの目的があります。

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

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

GCP リソース階層の詳細

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

G Suite と Cloud Identity のユーザーは、GCP リソース階層の他の機能にアクセスできます。リソースを集中管理し、フォルダなどのグループ化メカニズムを使用できます。Cloud Identity の管理ツールも用意されています。Cloud Identity を使用する方法については、Cloud Identity への移行方法をご覧ください。

GCP リソースは階層的に整理されています。階層の下からみると、プロジェクトが最初のレベルとなり、その中に他のリソースが存在します。どのリソースも 1 つのプロジェクトに属しています。

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

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

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

下の図に、GCP リソース階層の例を示します。

リソース階層

組織リソース

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

GCP ユーザーに組織リソースが必要なわけではありません。ユーザーが組織リソースを取得するのは、ユーザーが G Suite または Cloud Identity のユーザーの場合だけです。組織リソースは、G Suite または Cloud Identity アカウントと密接に関連しています。1 つの G Suite または Cloud Identity アカウントに 1 つの組織がプロビジョニングされます。ドメインに組織リソースを作成すると、アカウント ドメインのメンバーが作成するすべての GCP プロジェクトはデフォルトで組織リソースに属します。

説明を簡単にするため、ここでは G Suite を G Suite と Cloud Identity ユーザーの両方の意味で使用しています。

G Suite または Cloud Identity アカウントは会社を代表するアカウントで、組織リソースに対するアクセスの前提条件となります。GCP コンテキストでは、ID の管理、復旧、所有権、ライフサイクルの管理を行います。下の図は、G Suite や Cloud Identity と GCP リソース階層の関係を表しています。

G Suite 組織


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

組織リソースのメリット

組織リソースを使用すると、プロジェクトはそれを作成した従業員ではなく、組織に属します。従業員が会社を辞めたとしてもプロジェクトが削除されることはありません。プロジェクトは Google Cloud Platform 上で組織のライフサイクルに従います。

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

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

Resource Manager API を使用して作成した組織リソースは、次の内容から構成されます。

  • 組織を一意に表す識別子である組織 ID。
  • 変更可能な表示名。
  • 組織の作成時刻。
  • 組織の最終更新時刻。
  • 組織のオーナー。オーナーは組織リソースを作成するときに指定されます。いったん設定したら変更できません。これは、Directory API で指定された G Suite ユーザー ID です。

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

{
  "displayName": "myorganization",
  "organizationId":"34739118321",
  "createTime": "2016-01-07T21:59:43.314Z"
  "owner": {
    "directoryCustomerId": "C012BA234"
   }
}

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

フォルダ リソース

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

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

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

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

{
 "name" : "folders/my-folder",
 "parent" : "organizations/my-organization",
 "displayName" : "Engineering",
 "lifecycleState" : "ACTIVE",
 "createTime": "2016-01-07T21:59:43.314Z"
}

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

プロジェクト リソース

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

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

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

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

{
  "name": "myproject",
  "projectId": "my-project-123",
  "labels":
   {
     "my-label": "prod"
   },
   "projectNumber": "464036093014",
   "lifecycleState": "ACTIVE",
   "createTime": "2016-01-07T21:59:43.314Z"
}

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

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

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

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

IAM ポリシーの継承

Google Cloud Platform の Cloud Identity and Access Management(IAM)を使用すると、特定の Google Cloud Platform リソースに対するアクセス権を詳細に設定でき、他のリソースへの不要なアクセスを防止できます。IAM は、リソースに対して IAM ポリシーを設定することで、誰(ユーザー)がどのようなアクセス権(役割)をどのリソースに対して持つのかを制御できるようにします。

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

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

リソース階層


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

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Resource Manager のドキュメント