[Epic] SLSA Level 3

[flavio]

The SLSA requirements define that the provenance must unambiguously identify the output package by cryptographic digest, while also describing how the package was produced. Although SLSA Provenance v1 is recommended, there are no hard requirements on provenance format. Note that Docker buildx only supports v0.2, the upgrade is already on their backlog.

Both the SPDX SBOM and the Provenance can be embedded on a container image at building time by adding two flags to the docker buildx build command:

docker buildx build --push --sbom=true --attest type=provenance,mode=max -t "${IMAGE}" -f Dockerfile .

The provenance must account for the entire build process. When the build process is happening within the Docker buildx context, for example, the building of binaries or fetching of external dependencies must take place within one of the layers of a multi-staged container image.

No pre-built artefacts should be copied into a container image, unless that is tied to a specific version followed by some level of integrity checks. This is something to keep in mind while building the Policy Server container image, since right now the policy-server binary is built with cross-rs and then copied into the image.

The GitHub action docker/build-push-action, can enable the provenance and SBOM by adding these two lines:

     - name: Build and push image
       uses: docker/build-push-action@v6
       with:
         sbom: true
         provenance: mode=max

[viccuad]

List of artifacts:

• Ensure SLSA Lvl 3 in kubewarden-controller #898
• Ensure SLSA Lvl 3 in kwctl kwctl#933
• Ensure SLSA Lvl 3 in audit-scanner audit-scanner#384
• Ensure SLSA Lvl 3 in policy server policy-server#944
• Ensure SLSA Lvl 3 for kubectl image in helm-charts #907
• Ensure SLSA Lvl 3 for policy-reporter #908
• SPIKE: Ensure SLSA lvl 3 for policies #910
• Update docs at https://docs.kubewarden.io/tutorials/verifying-kubewarden
• Ensure SLSA Lvl 3 for helm chart OCI artifacts helm-charts#565

[viccuad]

For our kubectl image used in helm charts, as suggested by Flavio we could use the official kuberlr image, or the rancher/kuberlr-kubectl image. The latter has matching kubectl binaries pre-cached inside to be in lockstep with Rancher. This facilitates Kubewarden's airgap story too, hence I side with this approach.

[viccuad]

Policies can wait until later date.

[flavio]

Closing, everything has been done