概要
TerraformでGCP IAM設定をする際、google_project_iam_bindingの利用には注意が必要だ。
bindingリソースの挙動を把握していないと、新規にロールを有効化した際に既存のbindingリソースから意図せずロールを剥奪してしまう可能性があるからだ。
では、google_project_iam_bindingは使わないほうが良いのかーというと、別にそうでもないという話。
Terraform で GCP IAM 設定
google_project_iam_bindingは、任意のロールとその権限を有するアカウントとの対応関係を1:1でマッピングする。そのため、誤って同一ロールに対してbindingリソースを複数作成すると、新しく作られたリソースが優先され、古いリソースからはロールが剥奪されてしまう。
一方、google_project_iam_memberはその対応関係を1:nでマッピングできる。ゆえに、memberリソースを追加しても既存のリソースに影響を及ぼさず、複数のmemberリソースすべてに対してロールが有効化される。
この点は下記の記事に詳しい。 zenn.dev
google_project_iam_bindingを使うメリット
上記のような認識から、なんとなくgoogle_project_iam_bindingは指定せず、google_project_iam_memberを使えばいいじゃん……と思わないだろうか。
だが、bindingを指定することで整理されたtfが書ける。というのも、memberとbindingではロールを指定する方法が若干異なるためだ。
memberはひとつのリソースに対して、下記のようにメールアドレスが1件ずつしか指定できない。だから、同一のロールを複数のアカウントに紐付けたい場合は、memberリソースを繰り返し指定する必要があり、冗長な書き方を強いられる。
resource "google_project_iam_member" "project" { project = "hoge-project-id" role = "roles/editor" member = "user:taro@example.com" }
1件ずつロールとアカウントの紐付けを管理し、かつ管理外の設定（他のmemberリソース）と共存できる……というのがgoogle_project_iam_memberのpolicyなので、意味のある冗長さではあるのだが。
一方、bindingはメールアドレスをstringのスライスで書くため、下記のように複数行にわたって指定できる。
resource "google_project_iam_binding" "project" { project = "hoge-project-id" role = "roles/editor" members = [ "user:taro@example.com", "user:hanako@example.com", ] }
同一のロールを複数のアカウントに紐付けたい場合、memberよりもbindingを使うほうがstraightforwardなtfファイルが書ける。 bindingリソースのAuthoritativeな挙動を認識していれば、単純に書く分にはbindingを使うで良いと思う。
参考
memberやbindingにはそれぞれメリデメがあるので、悩んだら下記記事など参考にすると良さそう。
