概要

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

Cloud Platform のリソース階層と IAM ポリシー階層

Google Cloud Platform リソースは構造化された階層であり、組織リソースは階層内のルートノードで、プロジェクトは組織の子で、その他のリソースはプロジェクトの子です。各リソースの親は 1 つだけです。このようなリソースの階層構造のおかげで、親リソースでアクセス制御ポリシーと構成設定を指定でき、ポリシーと設定は、子リソースに継承されます。

次の図は、Cloud Platform のリソース階層の例を示しています。

リソース階層


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

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

たとえば、上記のリソース階層図では、bob@gmail.com に編集者の役割を付与するポリシーを i42Portal に設定し、alice@gmail.com に閲覧者の役割を付与する Compute Engine インスタンスを設定すると、Compute Engine インスタンスに対する編集者の役割を bob@gmail.com に、閲覧者の役割を alice@gmail.com に効果的に付与できます。

IAM のポリシー階層は Cloud Platform のリソース階層と同じパスに従います。リソース階層を変更すると、ポリシー階層も変更されます。たとえば、プロジェクトを組織に移動すると、そのプロジェクトの IAM ポリシーは、その組織の IAM ポリシーから継承するように更新されます。

組織

組織リソースは、組織を表し、Cloud Platform のリソース階層のルートノードです。組織リソースはプロジェクトの階層的なスーパーノードです。組織リソースに適用される IAM アクセス制御ポリシーは、その組織内のすべてのプロジェクト(したがって、プロジェクトの下にあるすべてのリソース)に適用されます。

組織リソースは Google for Work ドメイン アカウントと密接に関連しています。ドメインに組織リソースが作成されると、ドメインのメンバーが作成した Cloud プロジェクトは、すべて組織リソースに属します。この時点では、Google for Work 特権管理者のみがデフォルトの組織レベルの IAM ポリシーを変更し、IAM の役割を自分自身や他のユーザーに付与できます。組織管理者が作成されると、Google for Work 特権管理者に加え、追加された組織管理者も IAM ポリシーを変更できます。

組織リソースには、次の利点があります。

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

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

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

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

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

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

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

新しく作成された組織リソース用の最初の IAM ポリシーは、Google for work ドメインの全体にプロジェクト作成者の役割を付与します。組織リソースの作成時には他のリソースは作成されません。

組織の削除

組織リソースを削除するには、営業チームにお問い合わせください。

プロジェクト

プロジェクト リソースは、組織の下の次のレベルの構成エンティティです。すべての Google Cloud Platform のリソースはプロジェクト リソースに属します。

Google Cloud Resource Manager API を使用して作成したプロジェクト リソースは、次の内容から構成されます。

  • 2 つの識別子:

    • プロジェクトの一意の識別子であるプロジェクト ID。これは、プロジェクト作成時にユーザーが指定したものですが、プロジェクトの作成後には変更できません。そのため、プロジェクトの存続期間中、容易に使用できるような ID を選択してください。
    • プロジェクトを作成するときに自動的に割り当てられたプロジェクト番号。これは読み取り専用です。
  • 1 つの変更可能な表示名

  • プロジェクトのライフタイムの状態。例: ACTIVEDELETE_REQUESTED

  • プロジェクトのフィルタリングに使用できるラベルのコレクション。

  • プロジェクトが作成された時刻。

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

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

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

ラベル

label とは、プロジェクトに設定できるプロパティです。そのプロジェクトに含まれるリソースにラベルを付けることで、それらのリソースが整理しやすくなります。たとえば、test や prod などのラベルを設定することで、prod 内のすべてのリソースを一覧表示できます。ラベルを使用してリソースをフィルタリングすることで、リソースを簡単に検索および一覧表示できます。また、ラベルを使用して、コストを分析したり、一括オペレーションを実行したりするスクリプトを作成できます。プロジェクトにラベルを追加し、ラベルでプロジェクトをフィルタリングする手順については、ラベルを使用するをご覧ください。

プロジェクトの削除

Cloud Platform プロジェクトの削除には、主に次の 2 つのカテゴリがあります。

  • ユーザーが開始するプロジェクトの削除
  • 孤立したプロジェクトの削除

ユーザーが開始するプロジェクトの削除: delete() メソッドを使用して、自分が所有するプロジェクトを削除できます。このアクションは、プロジェクトを削除済みとしてマークしますが、プロジェクトはすぐには削除されません。プロジェクトを削除するようにマークすると、Cloud Platform がプロジェクトの lifecycle_stateDELETE_REQUESTED に設定します。この時点では、undelete() を呼び出してプロジェクトの削除を元に戻すことができます。プロジェクトは、その lifecycle_stateDELETE_REQUESTED である場合、list() メソッドを実行すると、引き続きその結果に表示されます。DELETE_REQUESTED が設定された数日後に、プロジェクトの削除プロセスが開始されます。この時点で、削除を元に戻すことは、もはや不可能です。プロジェクトの削除は、delete() リクエストの約 7 日後に開始されます。プロジェクトが削除されると、プロジェクトのすべてのオーナーに削除メールが送信されます。

孤立したプロジェクトの削除: Google Cloud Platform は孤立したプロジェクトを定期的に検出して削除します。孤立したプロジェクトとは、オーナーとしてのユーザーがいないプロジェクトのことです(サービス アカウントは、プロジェクトの削除に関してオーナーとしてはカウントされません)。孤立したプロジェクトには、オーナーとしてのユーザーが存在せず、その保留中の削除について通知するユーザーもいないので、孤児したプロジェクトの削除についてはメールによる通知は送信されません。孤立したプロジェクトが実際に削除されるまでに最大 15 日かかる場合があります。孤児したプロジェクトが組織リソースの一部である場合、そのプロジェクトは組織ノードが削除されるまで削除されないことに注意してください。

おすすめの方法

Cloud Resource Manager API を使用する際には、次の方法をおすすめします。

  • プロジェクトをポリシーの境界として使用する: Cloud プロジェクトを使って、同じ信頼境界を共有するリソースをグループ化します。プロジェクトは組織内の信頼境界を表します。同じプロジェクト内のサービスには、信頼のデフォルト レベルがあります。たとえば、App Engine インスタンスは同じプロジェクト内の Cloud Storage バケットにアクセスできます。プロジェクト レベルで付与された IAM の役割は、そのプロジェクト内のリソースによって継承されます。

  • Google for Work アカウントを使用して組織内にプロジェクトを作成する: 組織リソースを最大限活用するには、Google for Work アカウントを使用して Cloud リソースを作成および管理します。Google for Work アカウントを使用してプロジェクトを作成すると、そのプロジェクトは自動的に組織に関連付けられます。自社の従業員が作成したプロジェクトが組織に関連付けられていないことが判明した場合は、その従業員が Gmail アカウントのような一般ユーザー向けの Google アカウントを使用してプロジェクトを作成した可能性があります。

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

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

Google Cloud Resource Manager ドキュメント
Google Cloud Resource Manager ドキュメント