Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we running all cloudbuilds here? we're going to have quota issues fetching the logs etc and we're reducing the isolation of these subprojects??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(now someone's job that's only supposed to push some other subproject can also push to this staging location, right?)
lots of subprojects are not checking their logs closely when promoting images, if I understand what we're doing correctly: this is risky and we should go back to separate projects per subproject.
cc @kubernetes/sig-k8s-infra-leads
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the IAM permissions/ACL defined here not enough to handle this ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The plan is for all subprojects to share the single cloudbuild project. The quotas are very high(something like 30 concurrent jobs). k/k will run cloudbuild jobs on its own project given its complexity.
We enforce the expected behaviour by only allowing promoting images from specified sources that we review. In the extremely unlikely situation that a maintainer misconfigures their cloudbuild definition and publishes it against another subprojects registry, the image can't be promoted and is deleted after 90d and they will spot the errors.
Also, humans only have privileges to push to their own respective registries and only prow and infra admins can submit cloudbuild jobs. The only way a cloudbuild job can be submitted by maintainers is via a postsubmit defined in the image pushing folder in the trusted cluster and commits to main branches approved by maintainers.
This approach is much simpler and with a reasonable set of guardrails.