# AKIBA.SaaS「Google Cloud：組織作成の基礎」というテーマで登壇しました

概要

企業でGoogle Cloudを使用する上での第一ステップとなる「組織構造」について解説しました。
３大クラウドと言われているAWS,Azure,Google Cloudのそれぞれでは、リソースを大きな枠組みで管理する組織の概念が結構違ったりします。
Googleの方も仰っておりましたが、学習する際には一旦得意分野のクラウドの理解をリセットしながら進めていくのがいいかと思います。（知識が最初に戻り、少しめんどくさいかも知れませんが?）

資料

過去の類似の記事（参考）

Google Cloud：IdPとアカウント周りについてまとめた
Google Cloud：IAMのイメージについてざっくりまとめてみた
Google Cloud：Cloud Billingと組織の概要についてざっくりまとめてみた

組織階層を利用する理由

会社のセキュリティや管理面でのポリシーや規定を反映させる上で第一ステップとなる重要な項目です。
組織を作成して、その配下にプロジェクトをおくと組織の管理者が全てのプロジェクトを一元管理することが可能となりますので、企業でGoogle Cloudを運用する場合組織は必須です。（もちろん検証のみなら単一プロジェクトでも可）

組織の全体像

【ドメイン-組織→フォルダ→プロジェクト→リソース】
ドメインと組織は１：１
フォルダは組織配下に作成し、主に部門ごとに分ける用途などに使用する（フォルダを入れ子にすることは可能である）
フォルダ配下にプロジェクトを作成する、プロジェクトは各環境ごとに作成するのがよい（開発プロジェクト、運用プロジェクト、検証プロジェクト…etc）
※ Google Cloudから抜粋

Cloud Identityの作成

組織をドメインと紐付けるためには、その前にCloud Identityをセットアップして初期設定をしなければなりません。
または、既存のWorkspaceがあれば設定を行うことでCloud Identityの利用が可能となります。
手順として、【Cloud Idetityの作成】→【ドメイン所有権の証明】→【Google Project】の作成という流れで組織とプロジェクトを作成可能です。（Google Projectからの作成も可能です）
詳しくは下記公式ドキュメントや実際の作成ページを参照してください。

【参考】
Google Projectを作成する
Cloud IdentityのPremium版とFree版の比較
Cloud Identityに申し込む

組織内のリソース

フォルダの基本

フォルダは、組織の一部の集団（部門や課ごと）を区切る重要な役割を持ちます。
Google Cloudでの権限管理では前述で説明したように階層ごとに定義します。さらに組織、親フォルダのポリシーが子フォルダ子プロジェクトに引き継がれます（全て和集合となる）。
よって、最も上位の組織に付与する組織ポリシーは大きな範囲で定義をして（EIPの制限）、下位にいくにつれて細かな定義でポリシーを割り当てることをおすすめします。

プロジェクトの基本

プロジェクトはポリシーを適応させる最下層のリソースになります。（一部例外なリソースあり）
Compute EngineやCloud Storageなどのすべてのリソースが1つのプロジェクトに属します。
プロジェクト作成のベストプラクティスとして、環境ごと、アプリケーションごとに1つのプロジェクトを使用することが推奨されています。

（例）アプリA,Bがあるとして、開発、運用、テストを含めると計6つのプロジェクトとなる

プロジェクトを細かく分けることで、それぞれにアクセスポリシーを割り当てることや相互の設定の変更を分離でき、誤操作などのリスクを削減できます。

ポリシーとは

最後にポリシーの考え方について記述します。
それぞれの各要素の整理としては以下の通りになります。

エンティティ ＋ ロール（権限の集合体） ＝ ポリシー(ロールバインディング)

ポリシーを組織/フォルダ/プロジェクト/リソース（一部のみ）に適応させることができ、これにより権限管理を行います。

これらのポリシーはそれぞれの階層毎に継承されていきます。

まとめ

今回技術的な登壇が初めてで、そもそも私自身、オンラインセミナーや社外の人に何かを発表することの経験が全くなくいい経験になりました。
話すことは好きなので、どんどんGoogle Cloud関連の登壇をしてTop Engineerを目指して精進したいと思います。
あとはマジで痩せたい人は私に連絡ください。嘘抜きですぐに痩せさせます。✌️
（最後のスライドはおまけです）