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