Difference between google_project_iam_binding and google_project_iam_member

Terraform Providers Google
1

Hi terraform mates out there

I want to automate the role assignments process for service accounts and users on the Google Cloud Platform. I am actually thinking of creating IAM custom roles to get fine-grained roles terraform resources for different services, and assign that role to the users or service account I want to.

Checking the way to associate which members will get what roles, I am actually wondering what is the difference between use google_project_iam_binding and use google_project_iam_member resources.

My current understanding could fall on in using google_project_iam_binding to grant roles to service accounts and google_project_iam_member to user accounts, but I am not sure since in the documentation they use both to associate user accounts.

I also found this interesting article How to name your google project IAM resources in Terraform - Xebia

As you know, Google IAM resources in Terraform come in three flavors:

I didn’t know the previous sentence and I would like to deep dive in the way I can use policies, and IAM roles in a better way for my purpose.

2

The official documentation for this is at https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam:

Four different resources help you manage your IAM policy for a project. Each of these resources serves a different use case:

  • google_project_iam_policy: Authoritative. Sets the IAM policy for the project and replaces any existing policy already attached.
  • google_project_iam_binding: Authoritative for a given role. Updates the IAM policy to grant a role to a list of members. Other roles within the IAM policy for the project are preserved.
  • google_project_iam_member: Non-authoritative. Updates the IAM policy to grant a role to a new member. Other members for the role for the project are preserved.
  • google_project_iam_audit_config: Authoritative for a given service. Updates the IAM policy to enable audit logging for the given service.

In short, binding revokes any other members from the role to which it applies, whereas member just adds a member alongside existing members.

3

For anyone who stumbles upon this topic again:
There is also a feature / bug where the default service account from IAM pricipal is deleted.
Issue: Terraform google_project_iam_binding deletes GCP compute engine default service account from IAM principals · Issue #10903 · hashicorp/terraform-provider-google · GitHub

The debate on the issue is quite interesting, also for understanding. But in short:
Be very careful with google_project_iam_binding and google_iam_policy. If possible, use google_project_iam_binding instead!