Merge pull request #37841 from saschagrunert/dev-1.26-signed-artifacts

[KEP 3031] Add documentation about signed Kubernetes artifacts

content/en/blog/_posts/2022-05-03-kubernetes-release-1.24.md

@@ -32,7 +32,7 @@ Existing beta APIs and new versions of existing beta APIs will continue to be en
 
 Release artifacts are [signed](https://github.com/kubernetes/enhancements/issues/3031) using [cosign](https://github.com/sigstore/cosign) 
 signatures,
-and there is experimental support for [verifying image signatures](/docs/tasks/administer-cluster/verify-signed-images/). 
+and there is experimental support for [verifying image signatures](/docs/tasks/administer-cluster/verify-signed-artifacts/). 
 Signing and verification of release artifacts is part of [increasing software supply chain security for the Kubernetes release process](https://github.com/kubernetes/enhancements/issues/3027). 
 
 ### OpenAPI v3

content/en/blog/_posts/2022-08-18-kubernetes-1.24-release-interview.md

@@ -203,7 +203,7 @@ JAMES LAVERACK: This is really about encouraging the use of stable APIs. There w
 
 JAMES LAVERACK: That's correct. There's no breaking changes in beta APIs other than the ones we've documented this release. It's only new things.
 
-**CRAIG BOX: Now in this release, [the artifacts are signed](https://github.com/kubernetes/enhancements/issues/3031) using Cosign signatures, and there is [experimental support for verification of those signatures](https://kubernetes.io/docs/tasks/administer-cluster/verify-signed-images/). What needed to happen to make that process possible?**
+**CRAIG BOX: Now in this release, [the artifacts are signed](https://github.com/kubernetes/enhancements/issues/3031) using Cosign signatures, and there is [experimental support for verification of those signatures](https://kubernetes.io/docs/tasks/administer-cluster/verify-signed-artifacts/). What needed to happen to make that process possible?**
 
 JAMES LAVERACK: This was a huge process from the other half of SIG Release. SIG Release has the release team, but it also has the release engineering team that handles the mechanics of actually pushing releases out. They have spent, and one of my friends over there, Adolfo, has spent a lot of time trying to bring us in line with [SLSA](https://slsa.dev/) compliance. I believe we're [looking now at Level 3 compliance](https://github.com/kubernetes/enhancements/issues/3027).
 

content/en/docs/concepts/security/security-checklist.md

@@ -278,7 +278,7 @@ for time-bound service account credentials.
 - [ ] Container images are configured to be run as unprivileged user.
 - [ ] References to container images are made by sha256 digests (rather than
 tags) or the provenance of the image is validated by verifying the image's
-digital signature at deploy time [via admission control](/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller).
+digital signature at deploy time [via admission control](/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller).
 - [ ] Container images are regularly scanned during creation and in deployment, and
   known vulnerable software is patched.
 
@@ -301,7 +301,7 @@ Avoid using image tags to reference an image, especially the `latest` tag, the
 image behind a tag can be easily modified in a registry. Prefer using the
 complete `sha256` digest which is unique to the image manifest. This policy can be
 enforced via an [ImagePolicyWebhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook).
-Image signatures can also be automatically [verified with an admission controller](/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller)
+Image signatures can also be automatically [verified with an admission controller](/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller)
 at deploy time to validate their authenticity and integrity.
 
 Scanning a container image can prevent critical vulnerabilities from being

content/en/docs/tasks/administer-cluster/verify-signed-artifacts.md

@@ -1,12 +1,12 @@
 ---
-title: Verify Signed Container Images
+title: Verify Signed Kubernetes Artifacts
 content_type: task
-min-kubernetes-server-version: v1.24
+min-kubernetes-server-version: v1.26
 ---
 
 <!-- overview -->
 
-{{< feature-state state="alpha" for_k8s_version="v1.24" >}}
+{{< feature-state state="beta" for_k8s_version="v1.26" >}}
 
 ## {{% heading "prerequisites" %}}
 
@@ -19,6 +19,38 @@ You will need to have the following tools installed:
 - `cosign` ([install guide](https://docs.sigstore.dev/cosign/installation/))
 - `curl` (often provided by your operating system)
 
+## Verifying binary signatures
+
+The Kubernetes release process signs all binary artifacts (tarballs, SPDX files,
+standalone binaries) by using cosign's keyless signing. To verify a particular
+binary, retrieve it together with its signature and certificate:
+
+```bash
+URL=https://dl.k8s.io/release/v{{< skew currentVersion >}}.0/bin/linux/amd64
+BINARY=kubectl
+
+FILES=(
+    "$BINARY"
+    "$BINARY.sig"
+    "$BINARY.cert"
+)
+
+for FILE in "${FILES[@]}"; do
+    curl -sSfL --retry 3 --retry-delay 3 "$URL/$FILE" -o "$FILE"
+done
+```
+
+Then verify the blob by using `cosign`:
+
+```shell
+cosign verify-blob "$BINARY" --signature "$BINARY".sig --certificate "$BINARY".cert
+```
+
+{{< note >}}
+To learn more about keyless signing, please refer to [Keyless
+Signatures](https://github.com/sigstore/cosign/blob/main/KEYLESS.md#keyless-signatures).
+{{< /note >}}
+
 ## Verifying image signatures
 
 For a complete list of images that are signed please refer
@@ -28,7 +60,7 @@ Let's pick one image from this list and verify its signature using
 the `cosign verify` command:
 
 ```shell
-COSIGN_EXPERIMENTAL=1 cosign verify registry.k8s.io/kube-apiserver-amd64:v1.24.0
+COSIGN_EXPERIMENTAL=1 cosign verify registry.k8s.io/kube-apiserver-amd64:v{{< skew currentVersion >}}.0
 ```
 
 {{< note >}}
@@ -68,5 +100,5 @@ e.g. [conformance image](https://github.com/kubernetes/kubernetes/blob/master/te
 admission controller. To get started with `policy-controller` here are a few helpful
 resources:
 
-* [Installation](https://github.com/sigstore/helm-charts/tree/main/charts/policy-controller)
-* [Configuration Options](https://github.com/sigstore/policy-controller/tree/main/config)
+- [Installation](https://github.com/sigstore/helm-charts/tree/main/charts/policy-controller)
+- [Configuration Options](https://github.com/sigstore/policy-controller/tree/main/config)

content/en/releases/download.md

@@ -79,7 +79,7 @@ you can verify integrity for is a container image, using the experimental
 signing support.
 
 To manually verify signed container images of Kubernetes core components, refer to
-[Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-images).
+[Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-artifacts).
 
 
 

static/_redirects

@@ -588,3 +588,4 @@
 /zh/*         /zh-cn/:splat  302!
 
 /docs/concepts/overview/what-is-kubernetes/      /docs/concepts/overview/ 301
+/docs/tasks/administer-cluster/verify-signed-images/     /docs/tasks/administer-cluster/verify-signed-artifacts/   301