-
Notifications
You must be signed in to change notification settings - Fork 828
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
Create a prow job that scans proposed images against vulnerabilities #436
Comments
/cc @listx |
/assign rajibmitra |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale @yodahekinsew is working on this. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/close I'm closing this, if this became a problem again I'll open a new discussion |
@rikatz: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Damn sorry! I read the wrong issue /reopen |
@rikatz: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-lifecycle stale |
/sig release |
We now have this initial page that shows the vulns for the images we published https://storage.googleapis.com/k8s-artifacts-prod-vuln-dashboard/dashboard.html it is not beautiful, but I'm working to make it more "nice" and will open some discussion in RelEng to define the next steps. /note-myself to add this topic in the RelEng agenda |
@ameukam asked if we still want this service enabled for staging repos during today's k8s infra meeting |
I'm not sure. IMO it's really important for us to make sure the images we serve (at least the kubernetes one) does not contain any vulnerable package, but I guess it's worth to discuss with sig-security about this. For other images, this should be an opt-in. Maybe we should close this, and think from another perspective: does sig-release wants to scan the generated images? If so, instead of relying on GCP costs, maybe add a prow job that downloads the image and runs trivy or some other image scanner for problems, and break the CI if this happens, triggering an alert to update the image. @IanColdwater @tabbysable I guess it would be good to have some point of view from security here |
@kubernetes/release-engineering is this part of your v1.22 plans? |
/remove-milestone |
/milestone clear |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale Can reopen or recreate this issue when we've been able to give this more thought |
As talked with @listx on Slack:
It would be interesting to have some sort of Prow job that verifies staging images against vulnerabilities, using GCR Container Analysis or some other tool.
Any image trying a 'promotion' might need to be scanned and only promoted if its vulnerability score is lower than some defined threshold.
Also it would be interesting to have some sort of "Allowed CVE List" to bypass well-known false positives.
Edit: maybe related: kubernetes-sigs/promo-tools#144
The text was updated successfully, but these errors were encountered: