google_project_iam_xxxの違いとまとめ

GCPにおけるIAMの構造

• メンバー
  • ユーザ / グループ / サービスアカウント / ドメイン
• ロール（役割）
  • GCPのリソースに対する権限（例:GCSの管理者権限 / Projectの閲覧権限 など）
• IAMポリシー
  • ロールバインディングという名前で 「どのメンバーにどのロールを割り当てるのか？」 を管理する
  • 一定の条件（Condition) に基づくバイディングも可能

ポリシーについて  |  Cloud IAM のドキュメント  |  Google Cloud

Terraformのgoogle_project_iamについて

わかりづらいgoogle_project_iam系のリソースをまとめます。

これらは 指定のメンバーに対してロールを割り当てるポリシーを作成する 処理を行います。 ただし、以下の様な特徴があるので押さえておく必要があります。

名前	動作	宣言型 or 手続型
google_project_iam_policy	このリソースで指定した以外のポリシーが削除される	ポリシーに対して宣言的
google_project_iam_binding	既存のロールの削除は行わない。一方で、ロールを割り当てるメンバーを管理しているので、ここで指定したメンバーのみがロールを持つことができる 例：プロジェクト管理者権限を持つユーザをこのリソースで管理する場合、もしTerraformで管理しないユーザがいた場合そのユーザの管理者権限は剥奪される	ロールに対して宣言的
google_project_iam_member	既存のロールやユーザの権限を変更しない	手続型

google_project_iam_memberを使うのが基本的には安全です。 google_project_iam_policyとgoogle_project_iam_bindingは危険です！意図しないポリシー操作を行う場合があるので使わない方が身のためです！！！

その他

• google_service_account_iam
• google_spanner_database_iam
• google_storage_bucket_iam
• ...

などなどIAMを使って制御を行いたい代表的なGCPリソースに対して便利なTerraformリソースが用意されています。

これらのリソースを使用することで単純な「GCSへの読み込み」ではなく「バケットAの読み込み」などのような細かい設定を簡単に行うことができるようになります。

google_project_iamでもconditionにバケット名とか色々と条件つけられるのでやろうと思えばgoogle_project_iamだけで事足りる気もしますが、備え付けのリソースを使う方がTerraformのドキュメントを見るだけで済むので良さそうです。