-
-
Notifications
You must be signed in to change notification settings - Fork 384
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
By default enforce check of clone image via allow-list by image name and tag #4056
By default enforce check of clone image via allow-list by image name and tag #4056
Conversation
…hImageExact to compare container images
this enforce tag compare of images
Tearing down https://woodpecker-ci-woodpecker-pr-4056.surge.sh |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4056 +/- ##
=======================================
Coverage 26.96% 26.96%
=======================================
Files 394 394
Lines 27416 27416
=======================================
Hits 7393 7393
Misses 19323 19323
Partials 700 700 ☔ View full report in Codecov by Sentry. |
broke out the least controversial part: #4069 |
I think what's definitely a good idea is to support tag checks, but do not enforce them. Just like it's for the secrets. Together with removing all privileged plugins by default, wthe admin has the control about this then. |
it should be enforced in critical stuff ... else users just shoot themself in the foot |
…-tag' into plugin-secret-exact-filter-if-tag-set
Personally I think that allow-list is not the way to go, they takes a lot of resources and are hard to maintain for every instance. The best solution for this imho would be to have centrally managed vulnerable plugin version list that server would download at specific intervals and would trigger warnings in pipelines that use vulnerable plugin versions and allow woodpecker instance admins to block specific versions. This could be done not only for clone/trusted plugins but other plugins as well. |
that's an option we could go for ... |
Also we could have option that would automatically block vulnerable plugin versions if admin chooses to go this way |
as to my knowledge our clone plugin has no issues ... we can take our time to create a proper solution ... ... the best case would be to be able to have something like a CVE list just for containers ... but I dont know of none |
or also if you could specify container images if you file CVEs ... I wonder if I could propose some additional flag to the CVE list to specify ''artifacts'' or ''deply methodes'' so tools can check against the usge of them ... in this way we could then just file normal CVEs for plugins and use the official list to automatically create our own list, else it's also quite some maintinance burden on our side anyway ... |
I don't think the CVE list is the way to go and I don't think maintaining a list for us would be that hard as currently there haven't even been situations where that is the case and we could add them on issue/PR bases |
I also think a blocklist is more helpful here. Maintaining a list like this is not that nice |
ok we can close this in fafour of #4080 |
we currently allow all tags for our clone image. this change it to a an default allow list we maintain.