From 2bb982ff44e7bc91b6a47ccfeb16db74640da0f4 Mon Sep 17 00:00:00 2001 From: Felix Kronlage-Dammers Date: Tue, 17 Feb 2026 16:13:14 +0100 Subject: [PATCH 1/4] streamline this with SCS-0124 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In SCS-0124 we write: --- Critical (CVSS = 9.0 – 10.0): 3 hours High (CVSS = 7.0 – 8.9): 3 days Mid (CVSS = 4.0 – 6.9): 1 month Low (CVSS = 0.1 – 3.9): 3 months --- Our Policies should be the same where possible, so adjust this to match IaaS. Signed-off-by: Felix Kronlage-Dammers --- Standards/scs-0210-v2-k8s-version-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Standards/scs-0210-v2-k8s-version-policy.md b/Standards/scs-0210-v2-k8s-version-policy.md index 3698757c6..26a781772 100644 --- a/Standards/scs-0210-v2-k8s-version-policy.md +++ b/Standards/scs-0210-v2-k8s-version-policy.md @@ -59,9 +59,9 @@ the provided Kubernetes versions should be kept up-to-date with new upstream rel - The latest minor version MUST be provided no later than 4 months after release. - The latest patch version MUST be provided no later than 2 weeks after release. - This time period MUST be even shorter for patches that fix critical CVEs. - In this context, a critical CVE is a CVE with a CVSS base score >= 8 according + In this context, a critical CVE is a CVE with a CVSS base score >= 7 according to the CVSS version used in the original CVE record (e.g., CVSSv3.1). - It is RECOMMENDED to provide a new patch version in a 2-day time period after their release. + It is RECOMMENDED to provide a new patch version in a 3-day time period after their release. - New versions MUST be tested before being rolled out on productive infrastructure; at least the [CNCF E2E tests][cncf-conformance] should be passed beforehand. From 2c92f11c139ff729d0a841bb458fa95b277c48a4 Mon Sep 17 00:00:00 2001 From: Felix Kronlage-Dammers Date: Wed, 18 Feb 2026 07:35:12 +0100 Subject: [PATCH 2/4] explain the timeframe and scores better. Signed-off-by: Felix Kronlage-Dammers --- Standards/scs-0210-v2-k8s-version-policy.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Standards/scs-0210-v2-k8s-version-policy.md b/Standards/scs-0210-v2-k8s-version-policy.md index 26a781772..0f01aa775 100644 --- a/Standards/scs-0210-v2-k8s-version-policy.md +++ b/Standards/scs-0210-v2-k8s-version-policy.md @@ -58,10 +58,11 @@ the provided Kubernetes versions should be kept up-to-date with new upstream rel - The latest minor version MUST be provided no later than 4 months after release. - The latest patch version MUST be provided no later than 2 weeks after release. -- This time period MUST be even shorter for patches that fix critical CVEs. - In this context, a critical CVE is a CVE with a CVSS base score >= 7 according - to the CVSS version used in the original CVE record (e.g., CVSSv3.1). - It is RECOMMENDED to provide a new patch version in a 3-day time period after their release. +- This time period MUST be even shorter for patches that fix critical or high CVEs. + A critical CVE is a CVE with a CVSS base score >= 9.0 and a high CVE with a CVSS + base score >= 7.0 according to the CVSS version used in the original CVE record (e.g., CVSSv3.1). + It is RECOMMENDED to provide a new patch version in a 3-day time period after their release, this + comes from the BSI C5 Common Criteria[^1]. - New versions MUST be tested before being rolled out on productive infrastructure; at least the [CNCF E2E tests][cncf-conformance] should be passed beforehand. @@ -74,6 +75,8 @@ official sources as described in [Kubernetes Support Period][k8s-support-period] - It is RECOMMENDED to not support versions after this period in order to not encourage usage of out-of-date versions. +[^1]: [C5 criteria catalog with timeframes for responses on page 70.](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/CloudComputing/ComplianceControlsCatalogue/2020/C5_2020.pdf?__blob=publicationFile&v=3) + ## Related Documents All documents regarding versioning, releases, etc. for the official Kubernetes projects can From bda746a08b72980cf57ec9254843243d3e2cc859 Mon Sep 17 00:00:00 2001 From: Felix Kronlage-Dammers Date: Wed, 18 Feb 2026 11:08:34 +0100 Subject: [PATCH 3/4] revert this, we will add a v3 Signed-off-by: Felix Kronlage-Dammers --- Standards/scs-0210-v2-k8s-version-policy.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/Standards/scs-0210-v2-k8s-version-policy.md b/Standards/scs-0210-v2-k8s-version-policy.md index 0f01aa775..3698757c6 100644 --- a/Standards/scs-0210-v2-k8s-version-policy.md +++ b/Standards/scs-0210-v2-k8s-version-policy.md @@ -58,11 +58,10 @@ the provided Kubernetes versions should be kept up-to-date with new upstream rel - The latest minor version MUST be provided no later than 4 months after release. - The latest patch version MUST be provided no later than 2 weeks after release. -- This time period MUST be even shorter for patches that fix critical or high CVEs. - A critical CVE is a CVE with a CVSS base score >= 9.0 and a high CVE with a CVSS - base score >= 7.0 according to the CVSS version used in the original CVE record (e.g., CVSSv3.1). - It is RECOMMENDED to provide a new patch version in a 3-day time period after their release, this - comes from the BSI C5 Common Criteria[^1]. +- This time period MUST be even shorter for patches that fix critical CVEs. + In this context, a critical CVE is a CVE with a CVSS base score >= 8 according + to the CVSS version used in the original CVE record (e.g., CVSSv3.1). + It is RECOMMENDED to provide a new patch version in a 2-day time period after their release. - New versions MUST be tested before being rolled out on productive infrastructure; at least the [CNCF E2E tests][cncf-conformance] should be passed beforehand. @@ -75,8 +74,6 @@ official sources as described in [Kubernetes Support Period][k8s-support-period] - It is RECOMMENDED to not support versions after this period in order to not encourage usage of out-of-date versions. -[^1]: [C5 criteria catalog with timeframes for responses on page 70.](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/CloudComputing/ComplianceControlsCatalogue/2020/C5_2020.pdf?__blob=publicationFile&v=3) - ## Related Documents All documents regarding versioning, releases, etc. for the official Kubernetes projects can From 8d6d5dc7a9410b710405bc7c7ad49cf0e31790f7 Mon Sep 17 00:00:00 2001 From: Felix Kronlage-Dammers Date: Wed, 18 Feb 2026 21:18:00 +0100 Subject: [PATCH 4/4] add a v3 to address #1098 Signed-off-by: Felix Kronlage-Dammers --- Standards/scs-0210-v3-k8s-version-policy.md | 101 ++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 Standards/scs-0210-v3-k8s-version-policy.md diff --git a/Standards/scs-0210-v3-k8s-version-policy.md b/Standards/scs-0210-v3-k8s-version-policy.md new file mode 100644 index 000000000..e2be27b2f --- /dev/null +++ b/Standards/scs-0210-v3-k8s-version-policy.md @@ -0,0 +1,101 @@ +--- +title: SCS K8S Version Policy +type: Standard +status: Draft +track: KaaS +replaces: scs-0210-v2-k8s-new-version-policy.md +--- + +## Introduction + +The Kubernetes project maintains multiple release versions including their patched versions. +In the project, the three most recent minor releases are actively maintained, with a fourth +version being in development. As soon as a new minor version is officially released, +the oldest version is dropped out of the support period. +Kubernetes supports its releases for around 14 months. 12 of these are the standard +support period. The remaining 2 months are the end-of-life support period for things like: + +- CVEs (under the advisement of the Security Response Committee) +- dependency issues (including base image updates) +- critical core component issues + +More information can be found under [Kubernetes Support Period][k8s-support-period]. + +The [Kubernetes release cycle][k8s-release-cycle] is set around 4 months, which +usually results in about **3 minor** releases per year. + +Patches to these releases are provided monthly, except for the first patch, +which is usually provided 1-2 weeks after the initial release (see [Patch Release +Cadence][k8s-release-cadence]). + +## Motivation + +Kubernetes is a living, fast-paced project, which follows a pre-defined release cycle. +This enables forward planning with regard to releases and patches, but also implies a +necessity to upgrade to newer versions quickly, since these often include new features, +important security updates or especially if a previous version falls out of the support +period window. + +We want to achieve an up-to-date policy, meaning that providers should be mostly in +sync with the upstream and don't fall behind the official Kubernetes releases. +This is achievable, since new versions are released periodical on a well communicated +schedule, enabling providers and users to set up processes around it. +Being up-to-date ensures that security issues and bugs are addressed and new features +are made available when using SCS compliant clusters. + +It is nevertheless important to at least support all Kubernetes versions that are still +inside the support period, since users could depend on specific versions or may need +longer to upgrade their workloads to a newer version. + +The standard therefore should provide a version recency policy as well as a support +window period. + +## Decision + +In order to keep up-to-date with the latest Kubernetes features, bug fixes and security improvements, +the provided Kubernetes versions should be kept up-to-date with new upstream releases: + +- The latest minor version MUST be provided no later than 4 months after release. +- The latest patch version MUST be provided no later than 2 weeks after release. +- For patches that address high or critical CVEs it is RECOMMENDED to provide + a new patch version in a 3-day time period after their release, this is in + accordance with the BSI C5:2020[^1]. + +- This time period MUST be even shorter for patches that fix critical or high CVEs. + A critical CVE is a CVE with a CVSS base score >= 9.0 and a high CVE with a CVSS + base score >= 7.0 according to the CVSS version used in the original CVE record (e.g., CVSSv3.1). +- New versions MUST be tested before being rolled out on productive infrastructure; + at least the [CNCF E2E tests][cncf-conformance] should be passed beforehand. + +At the same time, providers must support Kubernetes versions at least as long as the +official sources as described in [Kubernetes Support Period][k8s-support-period]: + +- Kubernetes versions MUST be supported as long as the official sources support them + according to the [Kubernetes Support Period][k8s-support-period] and their end-of-life + date according to the [Kubernetes Releases page][k8s-releases]. +- It is RECOMMENDED to not support versions after this period in order to not encourage + usage of out-of-date versions. + +[^1]: [Cloud Computing Compliance Criteria Catalogue – C5:2020 with time frames for responses on page 70.](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/CloudComputing/ComplianceControlsCatalogue/2020/C5_2020.pdf?__blob=publicationFile&v=3#page=72) + +## Related Documents + +All documents regarding versioning, releases, etc. for the official Kubernetes projects can +be found on the [Kubernetes Releases page][k8s-releases]. + +## Conformance Tests + +The script `k8s_version_policy.py` requires a kubeconfig file with connection details for +a set of existing Kubernetes clusters that should be checked, with each of these clusters +representing one of the currently supported upstream Kubernetes releases. +It will check the encountered cluster versions according to the rules of this standard. +Rule violations will be reported on various logging channels: ERROR for mandatory rules +and INFO for recommended rules. +The script will exit with a non-zero status if a mandatory rule has been violated or if +the test could not be performed. + +[k8s-releases]: https://kubernetes.io/releases/ +[k8s-release-cycle]: https://kubernetes.io/releases/release/#the-release-cycle +[k8s-release-cadence]: https://kubernetes.io/releases/patch-releases/#cadence +[k8s-support-period]: https://kubernetes.io/releases/patch-releases/#support-period +[cncf-conformance]: https://github.com/cncf/k8s-conformance