Hardened Images?! #4112
-
|
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 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! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
As linked on Slack, this is covered in the docs: https://docs.rke2.io/security/about_hardened_images Note that 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. |
Beta Was this translation helpful? Give feedback.
-
All of the above images have proof of concept exploits against them? |
Beta Was this translation helpful? Give feedback.
-
|
I would defer to @macedogm on whether any of the vulnerabilities you are seeing are actually exploitable at runtime. I suspect not. |
Beta Was this translation helpful? Give feedback.
-
|
@macedogm I'll be happy to provide some further context into these issues. Especially around the hardened-kubernetes image, where there are proof of concept exploits against the kube-apiserver, kube-proxy, amongst others. |
Beta Was this translation helpful? Give feedback.
-
|
We're building the apiserver directly from upstream without modification, so if there are any "exploitable" vulnerabilities, those would most likely be the responsibility of upstream to fix - we don't patch Kubernetes itself for the purposes of hardening it. As discussed on the docs page linked above, our hardening comes mostly from the base image and use of goboring. If there are vulnerabilities that have been fixed by upstream, those would be addressed in the new patch release of Kubernetes itself, and published in a new image tag for that release - |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ChrisHolman. As described in RKE2 docs about hardened images, the hardened factor comes from the base images that we use to build on top (SLE BCI) plus FIPS compliance. We are not patching the upstream projects that are included on those images. So we must first wait for upstream to patch, then we can update the versions. As you might imagine, this can result on a long waiting cycle, test and release process that can be slow. Additionally, we are implementing automation in our repos to increase the frequency of updates and image bumps, but we can’t control and do the same with upstream dependencies. |
Beta Was this translation helpful? Give feedback.
As linked on Slack, this is covered in the docs: https://docs.rke2.io/security/about_hardened_images
Note that 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.