From 2a76398e3a131e43da9d2551b424cac94619b1a9 Mon Sep 17 00:00:00 2001 From: Kurt Garloff Date: Fri, 21 Aug 2026 14:39:44 +0200 Subject: [PATCH 1/3] New standard as discussed in SIG Std/Cert. One key motivation behind the k8s version policy is enabling users to keep their k8s clusters secure by having the latest k8s patch versions available without undue delay. We need more: The other software running on the nodes must include the latest security fixes as well. Require this in a separate standard scs-0220-v1 (Draft). Signed-off-by: Kurt Garloff --- Standards/scs-0220-v1-node-image-recency.md | 85 +++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 Standards/scs-0220-v1-node-image-recency.md diff --git a/Standards/scs-0220-v1-node-image-recency.md b/Standards/scs-0220-v1-node-image-recency.md new file mode 100644 index 000000000..e461266bc --- /dev/null +++ b/Standards/scs-0220-v1-node-image-recency.md @@ -0,0 +1,85 @@ +--- +title: SCS K8S Node Software Recency +type: Standard +status: Draft +track: KaaS +enhances: scs-0210-v2-k8s-version-policy.md +--- + +## Introduction + +In [scs-0210](scs-0210-v2-k8s-version-policy), +we require that latest patch versions for Kubernetes (k8s) to be +delivered soon after they are released. The motivation behind this is that the +latest k8s patches regularly address security-relevant issues, so the +availability of patch releases helps users to keep their clusters secure. + +Current k8s patch versions are typically delivered via new node images which +contain the needed kubernetes components (kubelet etc.). However, while it is +best practice to keep node images lean and small, they necessarily contain +software beyond kubernetes which may create security risks for users. When +writing scs-0210, the assumption was that the new k8s patch version would be +delivered through a new node image that would contain the latest relevant +security patches for all other included components, especially the Operating +System kernel (typically Linux). + +This expectation was not explicit and thus left room for interpretation and +was not a real requirement. Rather than adding it to the scs-0210 standard, +we capture it as a hard requirement in this new standard. + +## Decision + +In order to keep Kubernetes clusters safe, the node images need to contain +current patches for all relecvant security issues as they are available from +the upstream communities or Linux distributions. Users have the expectation +that moving to the latest Kubernetes patch version brings them not only all the +(security) fixes of the K8s patch but also all relevant available (security) +fixes at that point in time of other system components used on the k8s nodes. +SCS-compatible KaaS Operators need to fulfill this expectation. + +In particular this means that SCS-compatible KaaS Operators need to ensure +that: + +- Node images built and provided by them MUST only include software + projects or Linux distributions that receive security maintenance. +- Node images MUST be rebuilt or otherwise patched when (or after) a new + k8s patch version is provided by the KaaS operator and MUST include + at least all relevant security fixes available at the point in time of + the k8s patch release. + +We RECOMMEND that SCS-compatible KaaS Operators are prepared to deliver fixes +to node images also outside of new k8s patch versions for urgent cases. + +## Implementation notes + + + +This requirement can be fulfilled by rebuilding node images for each new +k8s patch version and basing the build on a Linux distribution that is +under security manintenance, including all released (security) fixes +and avoiding including packages that are unmaintained. In general, it +is a good idea to avoid the inclusion of unnecessary software and provide +minimal and hardened node images. + +If node images are registered as public or community images on an +SCS-compatible IaaS, the `build_date` property indicates that (at least) +all (security) fixes up to that date are included, see +[scs-0102](scs-0102-v2-image-metadata). + +Note that the qualifier "relevant" was used when requiring all released +security fixes to be included -- this leaves the door open to prove that +a specific software vulnerability can not affect the security of the node +image and thus may be excluded without violating this standard. We would +require that the reasoning is done publicly to provide transparency towards +the customers and undergo the scrutiny of the IT security community, so +this should only really be used in very exceptional circumstances. + +If the software on the K8s nodes is not delivered through images, the +operator still needs to ensure that the patches are applied and activated +no later than when the k8s patch version is applied. + +## Related Documents + +- SCS Kubernetes version policy standard [scs-0210](scs-0210-v2-k8s-version-policy). + This standard has a few references to the k8s lifecycle. + From 19e255cb8bd8aff8a8ce70de0eed629d58720204 Mon Sep 17 00:00:00 2001 From: Kurt Garloff Date: Fri, 21 Aug 2026 14:50:21 +0200 Subject: [PATCH 2/3] Address markdownlint nitpicks. Signed-off-by: Kurt Garloff --- Standards/scs-0220-v1-node-image-recency.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Standards/scs-0220-v1-node-image-recency.md b/Standards/scs-0220-v1-node-image-recency.md index e461266bc..a1e75fb01 100644 --- a/Standards/scs-0220-v1-node-image-recency.md +++ b/Standards/scs-0220-v1-node-image-recency.md @@ -61,13 +61,13 @@ and avoiding including packages that are unmaintained. In general, it is a good idea to avoid the inclusion of unnecessary software and provide minimal and hardened node images. -If node images are registered as public or community images on an +If node images are registered as public or community images on an SCS-compatible IaaS, the `build_date` property indicates that (at least) all (security) fixes up to that date are included, see [scs-0102](scs-0102-v2-image-metadata). Note that the qualifier "relevant" was used when requiring all released -security fixes to be included -- this leaves the door open to prove that +security fixes to be included - this leaves the door open to prove that a specific software vulnerability can not affect the security of the node image and thus may be excluded without violating this standard. We would require that the reasoning is done publicly to provide transparency towards @@ -82,4 +82,3 @@ no later than when the k8s patch version is applied. - SCS Kubernetes version policy standard [scs-0210](scs-0210-v2-k8s-version-policy). This standard has a few references to the k8s lifecycle. - From ac97b1d9dd3e9af245ecde485fd478089664e8e0 Mon Sep 17 00:00:00 2001 From: Kurt Garloff Date: Fri, 21 Aug 2026 16:33:13 +0200 Subject: [PATCH 3/3] Fix links (redirect to docs.scs.community/standards/) Signed-off-by: Kurt Garloff --- Standards/scs-0220-v1-node-image-recency.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Standards/scs-0220-v1-node-image-recency.md b/Standards/scs-0220-v1-node-image-recency.md index a1e75fb01..dd34ca498 100644 --- a/Standards/scs-0220-v1-node-image-recency.md +++ b/Standards/scs-0220-v1-node-image-recency.md @@ -8,7 +8,7 @@ enhances: scs-0210-v2-k8s-version-policy.md ## Introduction -In [scs-0210](scs-0210-v2-k8s-version-policy), +In [scs-0210](https://docs.scs.community/standards/scs-0210-v2-k8s-version-policy), we require that latest patch versions for Kubernetes (k8s) to be delivered soon after they are released. The motivation behind this is that the latest k8s patches regularly address security-relevant issues, so the @@ -64,7 +64,7 @@ minimal and hardened node images. If node images are registered as public or community images on an SCS-compatible IaaS, the `build_date` property indicates that (at least) all (security) fixes up to that date are included, see -[scs-0102](scs-0102-v2-image-metadata). +[scs-0102](https://docs.scs.community/standards/scs-0102-v2-image-metadata). Note that the qualifier "relevant" was used when requiring all released security fixes to be included - this leaves the door open to prove that @@ -80,5 +80,5 @@ no later than when the k8s patch version is applied. ## Related Documents -- SCS Kubernetes version policy standard [scs-0210](scs-0210-v2-k8s-version-policy). +- SCS Kubernetes version policy standard [scs-0210](https://docs.scs.community/standards/scs-0210-v2-k8s-version-policy). This standard has a few references to the k8s lifecycle.