diff --git a/keps/sig-release/3031-signing-release-artifacts/README.md b/keps/sig-release/3031-signing-release-artifacts/README.md new file mode 100644 index 00000000000..117bcb3fe86 --- /dev/null +++ b/keps/sig-release/3031-signing-release-artifacts/README.md @@ -0,0 +1,165 @@ +# KEP-3031: Signing release artifacts + + + +- [Release Signoff Checklist](#release-signoff-checklist) +- [Summary](#summary) +- [Motivation](#motivation) + - [Goals](#goals) + - [Non-Goals](#non-goals) +- [Proposal](#proposal) + - [User Stories (Optional)](#user-stories-optional) + - [Risks and Mitigations](#risks-and-mitigations) + - [Graduation Criteria](#graduation-criteria) + - [Alpha](#alpha) + - [Beta](#beta) + - [GA](#ga) +- [Drawbacks](#drawbacks) +- [Alternatives](#alternatives) +- [Implementation History](#implementation-history) + + +## Release Signoff Checklist + + + +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](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) + - [ ] (R) Minimum Two Week Window for GA e2e tests to prove flake free +- [ ] (R) Graduation criteria is in place + - [ ] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) +- [ ] (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 + + + +[kubernetes.io]: https://kubernetes.io/ +[kubernetes/enhancements]: https://git.k8s.io/enhancements +[kubernetes/kubernetes]: https://git.k8s.io/kubernetes +[kubernetes/website]: https://git.k8s.io/website + +## Summary + +Target of this enhancement is to define which technology the Kubernetes +community is using to signs release artifacts. + +## Motivation + +Signing artifacts provides end users a chance to verify the integrity of the +downloaded resource. It allows to mitigate man-in-the-middle attacks directly on +the client side and therefore ensures the trustfulness of the remote serving the +artifacts. + +### Goals + +- Defining the used tooling for signing all Kubernetes related artifacts +- Providing a standard signing process for related projects (like k/release) + +### Non-Goals + +- Discussing not user-facing internal technical implementation details + +## Proposal + +Every Kubernetes release produces a set of artifacts. We define artifacts as +something consumable by end users. Artifacts can be binaries, container images, +checksum files, documentation, provenance metadata, or the software bill of +materials. None of those end-user resources are signed right now. + +The overall goal of SIG Release is to unify the way how to sign artifacts. This +will be done by relying on the tools of the Linux Foundations digital signing +project [sigstore](https://www.sigstore.dev). This goal aligns with the +[Roadmap and Vision](https://github.com/kubernetes/sig-release/blob/f62149/roadmap.md) +of SIG Release to provide a secure software supply chain for Kubernetes. It also +joins the effort of gaining full SLSA Compliance in the Kubernetes Release +Process ([KEP-3027](https://github.com/kubernetes/enhancements/issues/3027)). +Because of that, the future [SLSA](https://slsa.dev) compliance of artifacts +produced by SIG release will require signing artifacts starting from level 2. + +[cosign](https://github.com/sigstore/cosign) will be the tool of our choice when +speaking about the technical aspects of the solution. How we integrate the +projects into our build process in k/release is out of scope of this KEP and +will be discussed in the Release Engineering subproject of SIG Release. A +pre-evaluation of the tool has been done already to ensure that it meets the +requirements. + +An [ongoing discussion](https://github.com/kubernetes/release/issues/2227) about +using cosign already exists in k/release. This issue contains technical +discussions about how to utilize the existing Google infrastructure as well as +consider utilizing keyless signing via workload identities. Nevertheless, this +KEP focuses more on the "What" aspects rather than the "How". + +### User Stories (Optional) + +- As an end user, I would like to be able to verify the Kubernetes release + artifacts, so that I can mitigate possible resource modifications by the + network. + +### Risks and Mitigations + +- **Risk:** Unauthorized access to the signing key or its infrastructure + + **Mitigations:** + + - Storing the credentials in a secure Google Cloud Project with + limited access for SIG Release. + - Enabling the cosign [transparency log + (Rekor)](https://github.com/sigstore/cosign#rekor-support) to make the key + usage publicly auditable. + - Working towards [keyless + signing](https://github.com/sigstore/cosign/blob/3f83940/KEYLESS.md) to + minimize the attack surface of the supply chain. + +### Graduation Criteria + +#### Alpha + +- Outline and integrate an example process for signing Kubernetes release + artifacts. + +#### Beta + +- Standard Kubernetes release artifacts (binaries and container images) are + signed. + +#### GA + +- All Kubernetes artifacts are signed. This does exclude everything which gets + build outside of the main Kubernetes repository. + +## Drawbacks + +- The initial implementation effort from the release engineering perspective + requires adding an additional layer of complexity to the Kubernetes build + pipeline. + +## Alternatives + +- Using the [OCI Registry As Storage (ORAS) project](https://github.com/oras-project/oras) + +## Implementation History + +- 2021-11-29 Initial Draft diff --git a/keps/sig-release/3031-signing-release-artifacts/kep.yaml b/keps/sig-release/3031-signing-release-artifacts/kep.yaml new file mode 100644 index 00000000000..84583bbe3d4 --- /dev/null +++ b/keps/sig-release/3031-signing-release-artifacts/kep.yaml @@ -0,0 +1,47 @@ +title: Signing release artifacts +kep-number: 3031 +authors: + - "@saschagrunert" +owning-sig: sig-release +participating-sigs: + - sig-security +status: provisional +creation-date: 2021-11-02 +reviewers: + - "@dlorenc" + - "@puerco" + - "@sftim" +approvers: + - "@cpanato" + - "@justaugustus" + +##### WARNING !!! ###### +# prr-approvers has been moved to its own location +# You should create your own in keps/prod-readiness +# Please make a copy of keps/prod-readiness/template/nnnn.yaml +# to keps/prod-readiness/sig-xxxxx/00000.yaml (replace with kep number) +#prr-approvers: + +# see-also: +# - "/keps/sig-aaa/1234-we-heard-you-like-keps" +# - "/keps/sig-bbb/2345-everyone-gets-a-kep" +# replaces: +# - "/keps/sig-ccc/3456-replaced-kep" + +# The target maturity stage in the current dev cycle for this KEP. +stage: alpha + +# The most recent milestone for which work toward delivery of this KEP has been +# done. This can be the current (upcoming) milestone, if it is being actively +# worked on. +latest-milestone: "v1.23" + +# The milestone at which this feature was, or is targeted to be, at each stage. +milestone: + alpha: "v1.23" + # beta: "v1.20" + # stable: "v1.22" + +# The following PRR answers are required at beta release +# metrics: +# - my_feature_metric