階層構造について
https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy?hl=ja
GCPのリソース階層は下位層から 見ていったほうがわかりやすいです。
プロジェクトは、フォルダにまとめることができます。フォルダには他のフォルダも格納できます。
組織が使用する全フォルダとプロジェクトは組織ノードの下にまとめられます。プロジェクト、フォルダ、組織ノードには、まとめてポリシーを定義できます。
一部のGCPリソースでは 個別にポリシーを定義できます。
たとえばCloud Storageバケットです。
ポリシーは階層の下位に 継承されます。すべてのGCPリソースは、１つのプロジェクトに属します。
プロジェクトはGCPサービスを使用する際の基本単位です。APIの管理、課金の有効化、 共同編集者の追加と削除などを行います。
各プロジェクトは独立した区画であり、各リソースは、1つの区画にのみ属します。
プロジェクトごとに異なるオーナーと、ユーザーを作成して個別に管理できます。
各GCPプロジェクトに、名前とプロジェクトIDを割り当てます。プロジェクトIDは永続的かつ不変で、GCP全体で一意である必要があります。
このIDは、さまざまな場面で使用します。そうすることで、GCPに作業対象のプロジェクトを指示します。
プロジェクトには、好きな名前を付けられます。
各プロジェクトには固有のプロジェクト番号も割り当てられます。
プロジェクトはフォルダにまとめることができます。フォルダは作業を楽にするためのツールです。
たとえばフォルダを使用して、組織内の各部門、チーム、アプリ、環境を表すことができます。
フォルダを使ってチームの管理権限を委任すれば、各チームが独立して対応できるようになります。
フォルダ内のリソースは、そのフォルダのIAMポリシーを継承します。
たとえばプロジェクト３と４が、同じチームによって管理される場合。
フォルダBにIAMポリシーを適用しますと、プロジェクト３と４のそれぞれに同じポリシーを 適用する手間もエラーの発生も抑えられます
フォルダを使用するには、階層の最上位に組織ノードが必要です。
社内の全プロジェクトは、１つの構造にまとめることができます。
大体の企業では、リソースの使用状況の確認と ポリシーの適用を一元的に行う必要があると思うのですが、それを可能にするのが組織ノードです！
組織ノードは階層の最上位階層であり、特別な役割を持っています。
たとえば、組織ポリシー管理者を指定して、管理者だけがポリシーを変更できるようにできます。
プロジェクト作成者の役割も割り当てられます。購入を行えるユーザを管理する効果的な方法です。
ただ、組織ノードはどのように作成するのでしょうか？
これは、会社がG Suiteを利用しているかどうかによって異なります。
G Suiteドメインがある場合、GCPプロジェクトは、自動的に組織ノードに属します。
そうでない場合は、Google Cloud Identityを使用して作成できます。
新しい組織ノードを作成した時点では、ドメイン内の全員が引き続き、プロジェクトと請求先アカウントを作成できます。
これは混乱を避けるためです。
なので、新しい組織ノードを作成したら、まずこれらの操作を許可するチームメンバーを決定したほうがよさそうです。
組織ノードを作成すれば、その下にフォルダを作成して、そこにプロジェクトを配置できます。
リソース整理の例を紹介します。
３つのプロジェクトがあり、それぞれが複数のGCPサービスのリソースを使用するとします。
この例ではフォルダを使用していませんが、プロジェクトはいつでもフォルダに移せます。
リソースは親リソースからポリシーを継承します。
たとえば組織レベルで設定したポリシーは、自動的にすべての子プロジェクトに継承されます。継承が遷移するということです。
つまり、プロジェクト内のすべてのリソースが、ポリシーを継承します。