This message was deleted.
# general
a
This message was deleted.
b
i
Thanks @big-judge-33880 - Looks like the classification of hardening comes from the fact it's using a hardened base image
rancher/hardened-build-base:v1.20.3b1
and only installing the necessary packages. I saw mention of Trivy too, but infact Trivy detects quite a few issues against this particular image
c
I can’t see to find anything to explain what has gone into that process.
https://docs.rke2.io/security/about_hardened_images
i
Copy code
RKE2 hardened images are scanned for vulnerabilities at build time
Any idea on what warrants a 'fix' based on the output of these scans? Only vulnerable components which can actively be exploited are fixed? Or any vulnerable component, regardless of exploitability?
c
we don’t ever re-release existing images, so you will never see them updated in-place to “fix” a vulnerability. Updates are delivered in newer image builds.
i
Yeah that was my question, when updates are delivered in newer builds, presumably they are also fixing the output of Trivy if it detects anything? Only I've tested the latest tag for etcd
rancher/hardened-etcd:v3.5.7-k3s1-build20230406
, (Albeit with Snyk, so a different detection engine) and noticed there are still issues against the golang libraries. Should i be reporting these? Or is it that you guys only fix issues if there are active exploits against them?
c
We have a security team that collects scanning results evaluates them, and plans updates for future releases. Just because something has a vuln doesn't mean it's actually exploitable in the process that the image is running. There is more to vulnerability analysis than just looking at scanner output.
i
Absolutely, the output of any tool generally can't be trusted without applying context - but having proof of concept exploits against key components (kube-apiserver being one) doesn't seem right. Hopefully Guilherme can help here
c
You can see our scan results in the public CI pipeline, I’m not aware of any “exploitable” vulnerabilities in our Kubernetes images. https://drone-publish.rancher.io/rancher/image-build-kubernetes/325/1/3
i
The issue here is with the dependencies. The base image, is clean, it's the 3rd parties being pulled in that contain issues: ✗ High severity vulnerability found in github.com/opencontainers/runc/libcontainer Description: Access Restriction Bypass Info: https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMOPENCONTAINERSRUNCLIBCONTAINER-3339620 Introduced through: github.com/opencontainers/runc/libcontainer@v1.1.1 From: github.com/opencontainers/runc/libcontainer@v1.1.1 ✗ High severity vulnerability found in github.com/opencontainers/runc/libcontainer Description: Improper Preservation of Permissions Info: https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMOPENCONTAINERSRUNCLIBCONTAINER-5296696 Introduced through: github.com/opencontainers/runc/libcontainer@v1.1.1 From: github.com/opencontainers/runc/libcontainer@v1.1.1 Fixed in: 1.1.5 ✗ High severity vulnerability found in github.com/emicklei/go-restful Description: Authorization Bypass Info: https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMEMICKLEIGORESTFUL-2435653 Introduced through: github.com/emicklei/go-restful@v2.9.5+incompatible From: github.com/emicklei/go-restful@v2.9.5+incompatible Fixed in: 2.16.0
Introduced through K8S_VERSION=v1.24.13 -- fixed in v1.26.4 of K8s
After some time spent down the rabbit hole, i can confirm they are not runtime issues, and should be fixed when the next official release of k8s is announced (Providing you guys always use latest)