BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Google Distroless Images Achieve SLSA Level 2

Google Distroless Images Achieve SLSA Level 2

Google announced that their distroless builds meet level 2 of the Supply chain Levels for Software Artifacts (SLSA). Level 2 requires that the build process for these images is tamper resistant. This improves on their previous release which saw all images being signed with cosign.

Distroless images are scaled down images with a greatly reduced surface area. These images do not include common tools such as shells or package managers. The smallest of the distroless images is less than 50% of the equivalent alpine image and less than 2% of the similar debian image.

To achieve SLSA level 2 the team implemented a number of improvements related to the build pipeline for these distroless images. This includes ensuring source code is version controlled, the build is scripted and run using a build service, and provenance is available, authenticated, and service generated. Provenance is metadata about how the artifact was built including information on ownership, sources, dependencies, and the build process used. Google previously released a proof of concept GitHub Action that demonstrates producing provenance in compliance with SLSA level 1.

Meeting these guidelines required a number of changes to the build pipeline. The team set up Tekton Pipelines and Tekton Chains in a Google Kubernetes Engine (GKE) cluster to automate the building of images and provenance generation. Each time a PR is merged to the distroless GitHub repo, the Tekton Pipeline is triggered building the image. Then the Tekton Chains generate the signed provenance for each image. That provenance is stored alongside the image in an OCI registry. A record of the provenance is also stored in the rekor transparency log.

With the distroless builds being fully reproducible with all the necessary build parameters recorded in the provenance, it is possible to rebuild the image entirely. This allows consumers to verify that the image matches the provided image digests. Verifying the attestation for a distroless image can be done with cosign and the distroless public key:

$ cosign verify-attestation -key cosign.pub gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91

Verification for gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.

The provenance from the rekor transparency log can be obtained for a given image using the rekor-cli tool:

$ rekor-cli search --sha sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91

af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8

$ rekor-cli get --uuid af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8 --format json | jq -r .Attestation | base64 --decode | jq

Distroless images by default do not contain a shell. The Dockerfile ENTRYPOINT command must be specified in vector form to avoid the container runtime prefixing with a shell. If needed there is a :debug image that provides a busybox shell for debugging purposes.

Chainguard recently moved their undistro image, Wolfi, into general availability. Similar to the distroless images, Wolfi is a minimal image that does not include a package manager or even a kernel. Each package included in Wolfi has a build-time SBOM (Software Bill of Materials) as standard. Vulnerability scans using Trivy show a marked reduction in CVE counts when compared to traditional distro-based images.

Supply chain security has seen significant investment in recent months due to an increasing threat landscape. A recent Aqua Security report found a 300% increase in supply chain attacks from 2020 to 2021. The recent Google 2022 Accelerate State of DevOps report focused its analysis on how organizations are securing their software supply chain. While the report found many practices are well adopted, there are still a number of recommended practices that are not widespread.

The team shared that they are now working on achieving SLSA level 3. That will require adding non-falsifiable provenance and isolated builds to their supply chain. Google's distroless images are available from GitHub and are free to use under the Apache License 2.0.

About the Author

Rate this Article

Adoption
Style

BT