Open natalysheinin opened 4 years ago
Hey @natalysheinin, we have two other types of IAM resources that will manage a policy without audit configs: _iam_binding resources, which are an authoritative list of members for a specific role, and _iam_member resources, which ensure that a specific member is present in the list for that role. We typically recommend that users use those less authoritative versions of the IAM resources, which also don't manage audit configs.
Is there a specific reason why you need to be using the google_iam_policy resource, or would the binding/member resources work for you?
I prefer using the google_iam_policy
because it's provides much tighter security controls over the entirety of the IAM bindings in a given resource (org/folder/proj/etc).
If I couldn't use google_iam_policy
, I would need to have 100+ empty bindings just to ensure that I am tracking the membership of every role. The terraform file would become to large and I'll never know if a new custom role or google-managed role is added that I am not tracking.
This makes sense, we support google_iam_policy
(the whole policy
entry), and google_iam_binding
(a single entry in bindings), but could support google_iam_bindings
to manage the bindings
item at https://cloud.google.com/resource-manager/reference/rest/Shared.Types/Policy
Community Note
Description
It is not possible to manage
google_project_iam_policy
without managing theaudit_config
policy.New or Affected Resource(s)
Potential Terraform Configuration
References