Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Excessive permissions in Scheduled Job example #498

Open
matthiasr opened this issue Sep 14, 2023 · 2 comments
Open

Excessive permissions in Scheduled Job example #498

matthiasr opened this issue Sep 14, 2023 · 2 comments
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@matthiasr
Copy link

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.0

Additional 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.

@matthiasr matthiasr added the bug label Sep 14, 2023
@msampathkumar msampathkumar self-assigned this Oct 2, 2023
@msampathkumar
Copy link
Contributor

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.

@matthiasr
Copy link
Author

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.

@msampathkumar msampathkumar removed their assignment Nov 29, 2023
@iennae iennae added the type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. label Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

4 participants
@matthiasr @iennae @msampathkumar and others