GCPのIAM（リソース）階層構造を理解する
pensukeGCPで用意されているリソース階層について
Organization → Folders → Projects → Resource
pensukeリソース階層を使用したアクセス制御
pensukeIAMのコンセプト
IAM では、誰（ID）がどのリソースに対してどのようなアクセス権（ロール）を持つかを定義することにより、アクセス制御を管理します。
https://cloud.google.com/iam/docs/overview?hl=ja
誰（ID）→メンバー
「誰」になれるのは下記4種類
- Google Account（userid@gmail.com）
- Service account 12345678@cloudservices.gserviceaccount.com
- Google Group（groupname@googleggroups.com）
- Google Workspace domain or Cloud Identity（alias@example.com）
- 要するにGoogle Workspace（旧GSuite）で作ったGoogleアカウント
- Cloud IdentityとはGoogle Driveとかが不要でIDのみ必要な人向けのIDaaS
このIDを組織、フォルダ、プロジェクト、リソースのいずれかに紐付けていく。
pensuke招待された組織外のメンバーはconsoleで組織なしのプロジェクトとして表示される
プロジェクトに組織外のGoogleアカウントを追加すると招待された側は「組織なし」として表示されるが、それは仕方ないっぽい。GCPの組織はGoogle Workspace（旧G Suite）と紐付いていて要するに組織へのユーザー追加は課金対象となる。
「組織なし」と表示されるのが気持ち悪いのでグループに追加したらどうか？と思ったけどそもそもGCPのリソース階層は Organization → Folders → Projects → Resource であり、 組織にプロジェクトがぶら下がることはあっても、Groupにプロジェクトがぶら下がることはない ために不可能。
そもそも小さいプロジェクトでは組織構造はまだ使わなくていいよってことなのでそういうものみたい。
新興企業であれば、組織リソースがないフラットなリソース階層構造からスタートします。プロジェクトの協力者やプロジェクトの数が増えてきてはじめて、組織リソースを導入する意味が生まれます。
https://cloud.google.com/iam/docs/resource-hierarchy-access-control?hl=ja#best_practices
pensukeTerraformで利用するcredentialはサービスアカウント単位でしか発行できない？
できないっぽい。チームでTerraform書くときは1人1人にServiceAccount発行するぐらいしかなさそう。もしくはそもそもCloudBuildでterraform applyするなど？
pensukegcloud auth application-default login でユーザーのcredentialを使うことができるけど production use-caseではサービスアカウントを使うのが良いみたい。
For a production use-case, you will want to use service account authentication, which you can learn about further down in this doc, but for experimenting, gcloud authentication will work fine.
pensuke別のページにもTerraform-specific なサービスアカウントを使うのが推奨方法って書かれてた。
Using Terraform-specific service accounts to authenticate with GCP is the recommended practice when using Terraform.
pensukeチームで利用する場合は下記のどちらかになりそう。
- Terraform-specificかつユーザー単位でサービスアカウントを発行する
- ユーザーがプロジェクトから抜けたらサービスアカウントごと消す
- GCP上でterraform applyする