Items marked with (R) are required prior to targeting to a milestone / release.
- (R) Enhancement issue in release milestone, which links to KEP dir in kubernetes/enhancements (not the initial KEP PR)
- (R) KEP approvers have approved the KEP status as
implementable - (R) Design details are appropriately documented
- (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors)
- e2e Tests for all Beta API Operations (endpoints)
- (R) Ensure GA e2e tests for meet requirements for Conformance Tests
- (R) Minimum Two Week Window for GA e2e tests to prove flake free
- (R) Graduation criteria is in place
- (R) all GA Endpoints must be hit by Conformance Tests
- (R) Production readiness review completed
- (R) Production readiness review approved
- "Implementation History" section is up-to-date for milestone
- User-facing documentation has been created in kubernetes/website, for publication to kubernetes.io
- Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
This document proposes a plan to harden the Kubernetes releases by making the necessary adjustments to comply with the SLSA Framework. SLSA (Supply-chain Levels for Software Artifacts) is a framework to harden software supply chains, currently in active development defined by the OpenSSF's Supply Chain Integrity WG.
The framework provides requirements and recommendations to software build systems to harden their environments and the processes that drive them. It also defines the metadata that needs to be produced to trace the origins of every item in a software release.
The main goal of this enhancement is to provide downstream consumers of our artifacts the highest assurance about the integrity of each Kubernetes release.
SLSA defines several levels of hardening, each touching more aspects of the release process that go beyond its technical implementation. This KEP proposes to use SLSA as a standard framework for hardening the Kubernetes release software supply chain. SIG Release will also recommend SLSA as a hardening framework to other projects under the Kubernetes organization, all new practices and tools derived from the effort in this KEP will be available for the benefit of those who choose to adopt it.
Release Kubernetes in a zero-trust environment.
Kubernetes releases represent key links in many software supply chains, not just for the project itself but also for consumers that derive, repackage and distribute our artifacts downstream. The project releases end-user artifacts like binaries and container images, but also source code that is actively reused further down the distribution stream.
All current work done by SIG Release on the Kubernetes supply chain centers around three focus areas: Artifact Consumption, Introspection, and Security. These areas are explained in more detail in our Roadmap for 2021 and Beyond document.
As the world hardens its software distribution methods, the Kubernetes project needs to do its part to achieve a secure supply chain from end to end: from the top base images to the final artifacts downloaded by end users. This proposal provides a path to achieve increasing levels of security, integrity, and availability in our releases by engineering new features to our processes. The objective is to achieve the highest possible compliance with the SLSA framework.
We consider SLSA compliance to be an effort in line with the three objectives outlined in our roadmap: Artifacts can be consumed easier and with more trust. Improvements to code and process will secure the supply chain and each release will produce software bills of materials, provenance attestations and signatures which will yield much better introspection to the journey from code to binary.
The SLSA framework is a project under the OpenSSF's Digital Identity Attestation Working Group. The framework defines numbered levels of compliance that harden software supply chains by recommending concrete steps to address, each of increasing technical complexity, number of stakeholders, and process adjuments necessary to reach them.
The main goal of this KEP is to define the highest possible SLSA compliance as final objective in enhancing the Kubernetes release process. While providing a roadmap this KEP can be considered complete when a SLSA level is deemed as not implementable by the community at large (see Graduation Criteria).
It is also the goal of this KEP to produce full documentation about changes to technical and human processes, tooling, and all artifacts produced as of the compliance effort. The documentation effort shall include complete specifications of provenance attestations and software bill of materials as well as handbook updates for contributors to follow.
This KEP does not aim to propose concrete technical implementation details or process improvements to achieve each SLSA level. As a framework, SLSA provides an incomplete roadmap to guide our implementation while it leaves the rest to the project. Some of these changes need a discussion and KEP by themselves, and we will be working on them as we advance.
The changes that need to be conducted include technical improvements (signing of artifacts, metadata generation, etc), setting up cryptographic key management systems and policy, VCS (GitHub) management, code review practices, and more. None of those concrete enhancements are under the scope of this document.
We propose to work on SLSA compliance in a predictable manner. As we move up the SLSA hardening levels, more and more stakeholders will be required to weigh in and to provide perspective about the required enhancements. Starting with SLSA 1, which is mostly a documentation effort, we plan to start having the discussions and presenting the necessary KEPs to work our way up.
The ideal outcome of this KEP would be to have a Kubernetes release process that complies with SLSA Level 4, meaning it is shielded from the most common threats to software supply chains. However, changes to reach level 4 may not be feasible.
If the changes that need to be conducted are deemed too disruptive or even destructive to other areas of the project (development velocity, contributor experience, policy, etc), the community may declare a specific SLSA level to be unimplementable. In that scenario, we would work on the rest of the SLSA requirements and consider this KEP complete.
Through signed artifacts, downstream users will be able to check the integrity of binaries, container images, documents, and other files that form part of a Kubernetes release.
Once the KEP is implemented, end-users will be able to verify the provenance of the artifacts we release. This means that the origin of each artifact will be traceable to its precise origin in the build process, with all parameters, inputs, code points, and other metadata available in a verifiable and non-repudiable format.
Signed supply chain metadata files, like the software bill of materials and the provenance attestations, will allow downstream consumers to ensure the integrity and completeness of a Kubernetes release. This means users can be sure that all expected artifacts are there, untampered, and also check that no extra items filtered into the release buckets, registries, etc.
Failure to pursue this enhancement poses two problems for the project.
SLSA requirements call attention to the most vulnerable areas of Software Supply Chains. Failure to pursue this enhancement leaves some of those areas exposed.
As projects up and down the stream harden their supply chains, Kubernetes cannot afford to be the weakest link. Our base images, the Distroless Images are SLSA 2 compliant now, for example. If we want to be good team players, our turn is up.
This KEP can be considered complete when the Kubernetes release process can be certified to be SLSA level 3 compliant.
Tracking issues and follow-up KEPs will be opened to track and discuss the viability of the required enhancements to reach each SLSA level. The SIG Release rodamap will be kept in sync, to reflect the state of the project.
The following is a rough, non-comprehensive outline of the work required to achieve each of the SLSA levels. It is important to note that some items and/or their specific implementations (like digital signing) will warrant a KEP of their own.
SLSA level 1 calls for consumer availability of build and release process information. The metadata provides a better overview of how software gets built. Only provenance attestations need be published to reach compliance.
Level 2 calls for digital signatures of the metadata captured and passed around the release process in the provenance attestations.
Work to reach SLSA 2 will center around three key areas:
-
Laying the required groundwork to enable SIG Release access to produce digital signatures. This enhancement is being proposed in KEP-3031.
-
Add the required improvements to sign the container images that are part of a Kubernetes release.
-
Add the required improvements to allow the release process to sign and verify artifacts as they travel through staging and release.
With those improvements in place, releases will produce signatures for their artifacts (images, binaries, tarballs, etc) as well as the release metadata (provenance attestations, SBOMs, etc).
The enhancements needed to reach SLSA Level 3 involve modifying the release process so that builds are controlled from configuration code checked into the VCS. Key areas for SLSA level 3 include:
-
Modifying the release process to run from configuration files that determine the build's outcome (relevant issue: k/release#1836)
-
The build process needs to be modified to ensure the parameters for running builds are accessible and recorded in the provenance statements.
Reaching SLSA level 4 demands hardening and reviewing of access controls and permissions to the build infrastructure, possibly a review of the PR approval process, and making the build process hermetic. Some requirements:
-
Modifying the release process to make available all dependencies before the build starts (tracking issue: k/sig-release#1720)
-
Ensuring that the release process meets a security standard. The framework does not require a specific one. This topic shall be proposed and discussed in a KEP when the time comes.
-
Ensuring that only an extremely limited number of individuals can override the guarantees provided by SLSA. This is mostly true at the moment but more transparency is needed to ensure risks and policies are understood by the community.
This KEP currently considers SLSA level 4 unimplementable. While the community has made great strides to move workloads to infrstructure under its control, the GCP projects that control the build process and artifact storage are not fully managed by relevant community groups (ie SIG K8s Infra). This makes it impossible to provide the access control and superuser guarantees required to reach SLSA level 4:
All physical and remote access must be rare, logged, and gated behind multi-party approval1.
Only a small number of platform admins may override the guarantees listed here. Doing so MUST require approval of a second platform admin2.
- 2021-10-31 Initial Draft
- 2021-11-17 Broader descriptions of required work for each SLSA level
- 2021-12-07 Scoped the KEP to SLSA3 and removed dual graduation criteria