Excessive permissions in Scheduled Job example
matthiasr opened this issue · comments
TL;DR
The "execute jobs on schedule" Cloud Run example creates permissions that are not needed, and binds project-level permissions where job-level binding would do.
Expected behavior
The example demonstrates the minimum permissions required to achieve the goal.
Observed behavior
It is unclear to the reader which permissions are required, or what they are used for.
Terraform Configuration
resource "google_cloud_run_v2_job_iam_binding" "run_invoker_binding" {
project = google_cloud_run_v2_job.default.project
location = google_cloud_run_v2_job.default.location
name = google_cloud_run_v2_job.default.name
role = "roles/run.invoker"
members = ["serviceAccount:${google_service_account.cloud_run_invoker_sa.email}"]
}Terraform Version
❯ terraform version
Terraform v1.5.5
on darwin_arm64
+ provider registry.terraform.io/hashicorp/google v4.80.0
+ provider registry.terraform.io/hashicorp/google-beta v4.80.0Additional information
I also needed roles/iam.serviceAccountUser for the account that actually applies the Terraform, but all examples seem to imply owner permissions on the project, so it does not need to be included in the example.
Hi @matthiasr, thank you the bug request. I have checked with others and here is the summary.
On a larger scale with lots of products and individuals working together, it is difficult to strike a balance between least privilege, minimum required roles, and easy to test/try samples. As a result, many examples often assume that the user has owner permissions on the project. This is done for simplicity and to make the examples easier to create and follow.
In my opinion, the author of the example is hinting at how to set the IAM role rather than what to set.
Let me know if you are any other suggestions I can check or pass on. Thank you.
To me, the how was not clear from the example at all. I spent a lot of time trying to figure out why the project binding is necessary, only to find that it isn't.