Add option to enable automations at Org level

[onetwopunch]

Currently you cannot enable at the org level and must enable at a list of folders. This may be desirable in many cases but many orgs have projects directly under the org that they would want autoremediation for. This can be as simple as adding a variable and corresponding logic in the terraform:

variable "grant-org-level-permission" {
  type        = bool
  default     = false
  description = "If true, grant automations permissions at the org level instead of folder level. This will take precedence over `folder-ids`."
}

[tomscript]

ya this is something we discussed a bit in the past. my personal feelings on the matter is i'd like to discourage this behavior as its just so much power to possess and (imo) its just not a good pattern to essentially grant org admin to a GCF. (understanding its not really org admin but the service account will likely have many roles assigned to it.) all it would take is one other service-account in the same project to have runAs to privilege escalate and take control of the entire org.

it could be made safer by adding in deny's etc but imo just granting at a lower level is generally less error prone and safer. having said all that i realize this is something some folks will want to do, which they can do now manually. but at least by keeping it out of terraform we don't actively encourage the behavior.

idk that is my thoughts and opinions on the matter. open to feedback of course.

[onetwopunch]

I have the same struggle of over permissioning service accounts, especially with stuff like Terraform in Cloud Build. I have two propositions.

1. Use the project-factory module to ensure that the automation project is isolated from other projects, thereby reducing the risk of someone else gaining access to actAs
2. Instead of a switch for allowing automations at the org level, have a separate list of projects that may be directly under the org level and also apply permissions to those. There are definitely scalability issues with both this and the current solution though as well as risk of shadow IT bypassing automation (i.e someone has folder creator at the org level, creates a new folder that isn't autoremediated.)

What are your thoughts?