Verifying Kubewarden Admission Controller

To verify the keyless-signed container images produced by the Admission Controller team, you can use the cosign CLI tool. For example, to verify the kubewarden/adm-controller/policy-server image, you can execute the following command:

You can then verify that the certificate in the returned JSON contains the correct issuer, subject, and github_workflow_repository extensions.

slsactl can also verify the images, once its identity table lists the shared workflow. At the time of writing it still expects the previous per-repository identity.

The same applies to all other images produced by the Admission Controller team, such as kubewarden/adm-controller and kubewarden/adm-controller/audit-scanner.

All container images also have SBOM and provenance files that can be used to ensure the secure supply chain of the images. You can find attestation files on the release page of the component or attached to the container image in the OCI registry.

We use Docker to build the images and their attestations. However, the cosign command does not yet support the verification of the attestations generated by Docker from the OCI registry. For this reason, you need to download the files from the release page or the registry and verify them locally. If you want to download the attestation files from the OCI registry, you can follow the Docker documentation and use tools like crane or docker itself to download the files from the registry.

When downloading the attestation files from the release page of the Admission Controller components, check them:

Now that the files integrity is verified, you can inspect the SBOM and Provenance files. You can get these from the container image, using `slsactl. For example:

The shared workflow runs actions/attest on the multi-architecture index of each image. GitHub writes the provenance from the OIDC token of the workflow job and signs it. No build step can change it. This attestation is what gives the images SLSA Build L3.

GitHub stores the attestation in the Admission Controller repository and next to the image in the registry. Verify it with the GitHub CLI:

--repo names the repository that stores the attestation. --signer-workflow names the workflow that signed it. The check fails for an attestation signed by any other workflow.

The SBOM and provenance files on the release page come from the container build. They carry the layer and build-arg detail that actions/attest does not. The actions/attest attestation is the one that carries the SLSA level.

You can find the Admission Controller Helm chart in our https:// traditional Helm repository under https://charts.kubewarden.io.

The same Helm chart is signed via Sigstore’s keyless signing, and pushed to an OCI repository that holds both the Helm chart and its provenance attestation as OCI artifacts.

The Helm chart is published alongside a Hauler manifest that lists all needed artifacts.

kwctl binaries are signed using Sigstore’s blob signing.

When you download a kwctl release each zip file contains a Sigstore bundle file that you can use for verification: kwctl-*bundle.sigstore.

In order to verify kwctl you need cosign installed, and then execute the following command:

You can then verify that the cert in the returned json contains the correct issuer, subject, and github_workflow_repository extensions.

The SBOMs are signed and published in the GitHub Releases of the project.

The provenance attestation for kwctl is verified by using gh attestation verify. For example

Policies maintained by the Admission Controller team are also signed using the Sigstore project. Similar to usual container images, one can verify them using cosign:

You can then verify that the cert in the returned json contains the correct issuer, subject, and github_workflow_repository extensions.