Hi there, We've been playing with RKE2 as a potential replacement for K3s. During our investigations, we've noticed RKE2 is pulling in a bunch of 'hardened' images: • rancher/hardened-etcd • rancher/hardened-coredns • rancher/hardened-k8s-metrics-server Amongst others... What constituents these images as hardened, what has been done? I can't see to find anything to explain what has gone into that process. After a quick Snyk scan against some of these images, the results don't look overly pretty, with many various libraries needing to be bumped. Any info would be appreciated, tks!

You could dig down through https://github.com/rancher/image-build-etcd/blob/master/Dockerfile

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

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?

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.

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?

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.

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

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

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