Skip to content

Latest commit

 

History

History
99 lines (61 loc) · 8.1 KB

readme.md

File metadata and controls

99 lines (61 loc) · 8.1 KB
Raw

01 - Generate and verify SLSA provenance

Highlight

Let's start by familiarizing ourselves with the goal of this activity.

Attacks prevented

Building with a high-level SLSA builder prevents build threats (E) "compromise build process", i.e., it prevents a build process compromise from infecting different builds. SLSA builders mitigates the threat by running each build process in an isolated, ephemeral environment. Beware of dependency caching in your build, since those may violate this property.

What you will need

Install the necessary software.

Provenance generation

SLSA provenance is generated by a builder. In this activity, we will use SLSA GitHub generator project. As described in the project's README, the project offers builders for various ecosystems. The project also support so-called "generators" which only generate provenance without changing your build definition. In a nutshell, you will build your container as you always do and simply call the generator at the end your workflow to generate the provenance. In this activity, we will use the container generator.

Provenance verification

To verify the provenance, we will use the slsa-verifier project. Verifying provenance requires am expected builder and a source repository name.

Deep dive

Provenance generation

Reading

Read the section Getting started of the container generator.

Create the workflow

Fork this repository https://github.com/slsa-framework/oss-na24-slsa-workshop-project1 by clicking this link.

The repository contains a GitHub workflow .github/workflow/build-echo-server.yml which builds and generates provenance for a hypothetical server. The file contains the following steps:

  1. Authenticate to docker registry.
  2. Build the container and push it to docker registry as "<repository-name>-echo-server". The image name is configured via an environment variable at the top of the workflow. The container code is stored in this repository under directory images/echo-server/ and is a simple echo server.
  3. In a seperate job, we call the container generator with the image name and digest. Note that is is IMPORTANT for the digest to be computed without pulling the image from the registry, because an attacker / insider could push a malicious image between our workflow push and pull.
  4. As a sanity step, we pull the container and run it.

Run the workflow

Follow these steps:

  1. Update the REGISTRY_USERNAME to your own docker registry username.
  2. Update the hardcoded username used to store the provenance to registtry.
  3. Create a docker regitry token with read, write and delete access.
  4. Store your docker token as a new GitHub repository secret called REGISTRY_PASSWORD: Settings > New repository secret.
  5. Run the workflow via the GitHub UI. It will take ~2mn to complete. If all goes well, the workflow run will display a green icon. Click on the job run called "run" (see example run). Note the name of the container displayed in the logs. In the example above, it is docker.io/laurentsimon/oss-na24-slsa-workshop-project1-echo-server@sha256:51c374c1af56022fdc75aec399d9694e1559338544d78b788a515bdd7278ebf5.

Verify provenance

Install the slsa-verifier.

Make sure you have access to your image by authenticating to docker:

$ REGISTRY_TOKEN=<your-token>
$ REGISTRY_USERNAME=<registru-username>
$ docker login -u "${REGISTRY_USERNAME}" "${REGISTRY_TOKEN}"

To verify your container, use the following command:

# Update the image as recorded in your logs
$ image=docker.io/laurentsimon/oss-na24-slsa-workshop-project1-echo-server@sha256:51c374c1af56022fdc75aec399d9694e1559338544d78b788a515bdd7278ebf5
$ source_uri=github.com/slsa-framework/oss-na24-slsa-workshop-project1
$ path/to/slsa-verifier verify-image "${image}" --source-uri "${source_uri}" --builder-id=https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml

The slsa-verifier verifies:

  1. The cryptographic digest of the container matches the one in the attestation
  2. The source origin of the repository
  3. The builder who built and generated the attestation.

Pass command --print-provenance | jq to see the verified content of the attestation.

Explore other commands by using the --help command. You can read more on the project repository.

Run the same verification command but remove the sha256:xxx part of the image name: image=idocker.io/laurentsimon/oss-na24-slsa-workshop-project1-echo-server. Why is this failing? See hints.

Optional: Verification in a GitHub workflow

Add a job to your workflow and verify its provenance in the workflow. You can install the slsa-verifier as a step in your workflow with its GitHub Action.

Read about the limitations of the current implementation of the generators.

Take the quizz!

After completing this activity, you should be able to answer the following questions:

  1. What is a SLSA builder?
  2. What is a SLSA level? What does it represent? What component do we associate it to?
  3. What is SLSA provenance? What information does it contain?
  4. What is the necessary metadata to verify SLSA provenance for an artifact?
  5. Read about dependency caching. How might it impact the security of your builds?