-
Notifications
You must be signed in to change notification settings - Fork 288
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
Allow trusted builders by repo or tag #2266
base: main
Are you sure you want to change the base?
Conversation
a8f525c
to
cb8f978
Compare
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.
Thank you for the contribution @modulo11 - the implementation looks solid.
I do want to circulate this a bit more to ensure that folks are on board with it - I've added it to the agenda for the next working group. There are two things to note:
- We'll auto trust deprecated images (e.g., heroku/builder:22) in this case, but we do that already (because heroku/builder:22 is on the trusted list though it's not suggested)
- We could end up auto-trusting "dev" images, which worries me a little. Folks might not be placing the same care into the creation of those images compared to ones that get promoted to production. But that seems more of a risk for bugs vs malicious content.
@natalieparellano any updates from the working group meeting? |
I missed it 🙀 - @jabrown85 do you recall if this was discussed? |
Ah yeah - we did discuss this one the other day. The consensus of the those in the Working Group was that we like the idea of being able to trust a repo. E.g. |
Awesome - thank you @jabrown85! @modulo11 would you be able to update the implementation to reflect that? |
60de1ed
to
6dc5051
Compare
Signed-off-by: Johannes Dillmann <[email protected]>
6dc5051
to
c639827
Compare
I updated the PR according to the discussion. The current behavior (also seen in the tests) is:
|
Summary
With this change, the tag part of a trusted builder is ignored. Trusting a builder
my/registry/builder
at the moment does not also trustmy/registry/builder:latest
, which should be the same image. Following up on a Slack discussion, it might be more intuitive for users to trust an image regardless of any tag.I took the opportunity to extract trusted/known builder handling into a common location.
Documentation