-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add blog post about binary artifact signing
Signed-off-by: Sascha Grunert <[email protected]>
- Loading branch information
1 parent
3d14225
commit 9fd0384
Showing
1 changed file
with
84 additions
and
0 deletions.
There are no files selected for viewing
84 changes: 84 additions & 0 deletions
84
content/en/blog/_posts/2022-12-XX-kubernetes-release-artifact-signing.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,84 @@ | ||
| --- | ||
| layout: blog | ||
| title: "Kubernetes 1.26: We're now signing our binary release artifacts!" | ||
| date: 2022-12-6 | ||
| slug: kubernetes-release-artifact-signing | ||
| --- | ||
|
|
||
| **Author:** Sascha Grunert | ||
|
|
||
| The Kubernetes Special Interest Group (SIG) Release is proud to announce that we | ||
| are digitally signing all release artifacts, and that this aspect of Kubernetes | ||
| has now reached _beta_. | ||
|
|
||
| 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. The overall goal of out past work was to define the used tooling for | ||
| signing all Kubernetes related artifacts as well as providing a standard signing | ||
| process for related projects (for example for those in [kubernetes-sigs][k-sigs]). | ||
|
|
||
| [k-sigs]: https://github.com/kubernetes-sigs | ||
|
|
||
| We already sign all officially released container images from Kubernetes v1.24, | ||
| which was still an _alpha_ feature until v1.25. Now in v1.26, we added all | ||
| **binary artifacts** to the signing process as well! This means that now all | ||
| [client, server and source tarballs][tarballs], [binary artifacts][binaries], | ||
| [Software Bills of Material (SBOMs)][sboms] as well as the [build | ||
| provenance][provenance] will be signed using [cosign][cosign]. Technically | ||
| speaking, we now ship additional `*.sig` (signature) and `*.cert` (certificate) | ||
| files side by side to the artifacts for verifying their integrity. | ||
|
|
||
| [tarballs]: https://github.com/kubernetes/kubernetes/blob/release-1.26/CHANGELOG/CHANGELOG-1.26.md#downloads-for-v1260 | ||
| [binaries]: https://gcsweb.k8s.io/gcs/kubernetes-release/release/v1.26.0/bin | ||
| [sboms]: https://storage.googleapis.com/kubernetes-release/release/v1.26.0/kubernetes-release.spdx | ||
| [provenance]: https://storage.googleapis.com/kubernetes-release/release/v1.26.0/provenance.json | ||
| [cosign]: https://github.com/sigstore/cosign | ||
|
|
||
| To verify an artifact, for example `kubectl`, you can download the | ||
| signature and certificate alongside with the binary: | ||
|
|
||
| ```shell | ||
| curl -sSfL https://dl.k8s.io/release/v1.26.0/bin/linux/amd64/kubectl -o kubectl | ||
| curl -sSfL https://dl.k8s.io/release/v1.26.0/bin/linux/amd64/kubectl.sig -o kubectl.sig | ||
| curl -sSfL https://dl.k8s.io/release/v1.26.0/bin/linux/amd64/kubectl.cert -o kubectl.cert | ||
| ``` | ||
|
|
||
| Then you can verify `kubectl` using [`cosign`][cosign]: | ||
|
|
||
| ```shell | ||
| cosign verify-blob kubectl --signature kubectl.sig --certificate kubectl.cert | ||
| ``` | ||
|
|
||
| All of the mentioned steps as well as how to verify container images are | ||
| outlined in the official documentation about how to [Verify Signed Kubernetes | ||
| Artifacts][docs]. In one of the next upcoming Kubernetes releases we will | ||
| working making the global story more mature by ensuring that truly all | ||
| Kubernetes artifacts are signed. Beside that, we consider to use Kubernetes | ||
| owned infrastructure for the signing (root trust) and verification (transparency | ||
| log) process. | ||
|
|
||
| [docs]: /docs/tasks/administer-cluster/verify-signed-artifacts | ||
|
|
||
| If you're interested in contributing to SIG Release, then consider applying for | ||
| the upcoming v1.27 shadowing program (watch for the announcement on | ||
| [k-dev][k-dev]) or join our [weekly meeting][meeting] to say _hi_. | ||
|
|
||
| We're looking forward to shipping more of those awesome features in future | ||
| Kubernetes releases. For example, we're working on the [SLSA Level 3 Compliance | ||
| in the Kubernetes Release Process][slsa] or the [Renaming of the kubernetes/kubernetes | ||
| default branch name to `main`][kkmain]. | ||
|
|
||
| Thank you for reading this blog post! Feel free to reach out to us by using the | ||
| [SIG Release mailing list][mail] or the [#sig-release][slack] Slack channel. | ||
|
|
||
| [mail]: https://groups.google.com/g/kubernetes-sig-release | ||
| [slsa]: https://github.com/kubernetes/enhancements/issues/3027 | ||
| [kkmain]: https://github.com/kubernetes/enhancements/issues/2853 | ||
| [slack]: http://slack.k8s.io | ||
| [k-dev]: https://groups.google.com/a/kubernetes.io/g/dev | ||
| [meeting]: http://bit.ly/k8s-sig-release-meeting | ||
|
|
||
| #### Additional resources | ||
|
|
||
| - [Signing Release Artifacts Enhancement Proposal](https://github.com/kubernetes/enhancements/issues/3031) |