improve handling of service agents with google_project_iam_policy and google_iam_policy

[ggprod]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

This is a request to improve service agent handling when setting project-level IAM policy via the resource google_project_iam_policy and the data source google_iam_policy. Currently unless you explicitly include service agents when setting google_project_iam_policy (via bindings defined in a coresponding data source google_iam_policy) the bindings of service agents will be removed. I'm proposing some way of using this which would allow declarative setting of all other project bindings without interfering with the default service agent bindings.

This may not be possible in terraform without changing the underlying GCP APIs (though I don't know where to log an issue for that)

New or Affected Resource(s)

• google_XXXXX

Potential Terraform Configuration

# Propose what you think the configuration to take advantage of this feature should look like.
# We may not use it verbatim, but it's helpful in understanding your intent.

References

• #0000

[eriksw]

Please consider that google_project_iam_policy may be used with the explicit intention to robustly ensure that certain automatically-created service accounts with problematically-broad default privileges are deprivileged.

This should not be implemented without some way to have terraform ensure that a grant is not present, or that a given principal does not have any grants—right now all the resources except google_project_iam_policy are only additive, necessitating fragile exec-based workarounds.

Of particular note would be the default compute service account and the cloudbuild service account.

[ggprod]

@eriksw I'm envisioning perhaps a new resource manager API (yes, I realize this is out of scope of the terraform google provider but I imagine there is some overlap and/or two-way communication between your group and the GCP API maintainers) that provides the set of default role bindings for the active service agents in the project ... this could then be union-ed with the desired project IAM policy binding captured in a data source google_iam_policy config, thereby providing a way to declare all project IAM policy bindings without interfering with default service agent bindings (or being forced to manually declare them in the google_iam_policy config).. that seems sensible and something I believe many users may appreciate (how many users don't use the default role bindings with whichever service agents are active in the project, based on the activated services/APIs, for those that do you could add a boolean parameter to disable this service-agent defaulting behavior)

Also, by service agent I mean those google-managed service accounts that have service agent in their name and typically represent Google APIs acting in or on the project's behalf (so not including the cloud build SA or compute engine or app engine default service accounts)

[slevenick]

I don't think this is something we will reasonably be able to handle within the provider. Unfortunately the logic around which service accounts permissions need to exist for the default service accounts to work is somewhat complex, as some services need more permissions than the default to work correctly.

We likely don't want to add complex logic around what default roles should exist for specific service agents, as this may change over time and fall out of date. If this was provided by the API it would be a more reasonable undertaking, but lacking support on that I'm going to close this as infeasible.

You can request API changes here: https://cloud.google.com/support/docs/issue-trackers#trackers-list

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.