What is the difference between google_project_iam and google_service_account_iam?

Question

Regarding these two Terraform GCP resources : google_project_iam and google_service_account_iam

I can't fully grasp the differences and use cases were you should use one over the other. I might have one, where you would want to create a workloadIdentity only through google_service_account_iam (as in this topic: How to create the GCP workload identity IAM bindings in Terraform?).

Within these two types of resources, I also do not fully understand the differences between the iam possibilities there: "iam_policy, iam_binding, iam_member"

Does anyone has uses cases where you would want/need one over the other in a google_project_iam context? And regarding a google_service_account_iam context?

Answer 1

I will try to dissipate the fog, but I totally agree: it's unclear!

For your first question:

• google_project_iam grants an account (service account, user account or google group) a role on the project. When you do that, the account has the role over ALL the resource on the project (grant BigQuery Data Viewer, the account can view all the data, of all dataset, of all tables). Note: here you can restrict the data access by granting the account on the dataset only and not on the whole project
• google_service_account_iam grants an account (service account, user account or google group) a role on the service account. And... the weird thing happens!! In Google Cloud, a service account is an identity (of a machine) but also a resource. And therefore you can grant permission on this resource. Could be strange, but there is a use case: if you want to allow an account to impersonate only a specific service account (and not all the service account of the project). Impersonation allows an account to perform operation on behalf of another account (here the service account). Use this terraform primitive only for impersonation.

---

For the 2nd question, it's pretty easy, it's in the terraform documentation. But let me summarise:

• iam_policy: The most dangerous: it replaces (so delete the existing ones and put what you set in your terraform config) all the roles with their granted accounts on the resource
• iam_binding: it replaces (so delete the existing ones and put what you set in your terraform config) for a single role, their granted accounts on the resource
• iam_member: the safer: it only adds the current role and accounts on the resource

With the 2 first one, you delete the existing configuration (things done manually or stuff like that). Therefore, if you are not sure about your terraform, you can lose access to the resource (especially at the project level!)