Make Gitpod SLSA Level 1 compliant by providing in-toto provenance

[csweichel]

Description

This PR updates leeway to the latest release which supports generating SLSA provenance as part of the build. With this change, for every subsequent build, we find out what went into this build. In the future, with the addition of signatures (already supported by leeway), we can find out if the build - or the leeway cache - has been tampered with.

Use-cases for this change:

• leeway relies heavily on caching, and prior to this change modifications of the cache were undetectable. This change makes the entire chain traceable.
• when we deploy code to production, or release new self-hosted versions, we want to make sure we're actually shipping what we believe we're shipping. With this change we can make assertions against the collected provenance to ensure that e.g. all code was built from a clean working copy (i.e. actually came out of the Git repo). In benign cases someone accidentally modified the build cache or pushed an image under a false tag.
• we've had instances in the past where we did not fully trust the build cache or did not understand where a build was coming from. Although those cases have become exceedingly rare now that leeway has become much more stable, we might still see those kind of issues.
• once this PR is merged, imho Gitpod is SALSA level 1 compliant, which is something more and more organisations care about.

See below's Loom video for more detail.

Caveats

• our CI builds do not run from a clean working copy, but have e.g. .gradle/ or go/ directories. leeway has a fallback mode where if the working copy is dirty, it collects the materials from the package sources directly. We want to get to a state where build from a clean working copy, to ensure that we're truly building directly from Git.
• we're not signing the provenance just yet, and it's not quite clear how to do that in a way that makes sense. We'd need to make the private key available during the CI builds which all but places it in the open. I'm wondering how other organisations handle this.
• this is super early days, and closer to a PoC than to production ready code. There aren't a whole lot of tools out there that produce SLSA provenance, neither are there too many consumers just yet.
• we don't have a good way to distribute the provenance (attestation bundles) we produce. All cached leeway build artefacts carry their attestation bundle, but that's not really accessible. We also place the bundle in the version and installer Docker images that come out of the build.

How to test

Best way is to inspect the provenance generated for the build:

# get the provenance of a build from the version image
docker run --rm -it eu.gcr.io/gitpod-core-dev/build/versions:cw-bump-leeway.30 cat /provenance-bundle.jsonl > prov.jsonl

# decode the envelope payloads
cat prov.json | jq -r .payload | base64 -d > prov-decode.jsonl

# ensure that everything was built using leeway (requires a [recent leeway version](https://github.com/gitpod-io/leeway/releases/tag/v0.2.16))
leeway provenance assert --built-with-leeway file://prov.jsonl

# ensure that everything was built directly from Git (will fail)
leeway provenance assert --git-only file://prov.jsonl

Release Notes

Provide SLSA/in-toto provenance for the build

[github-actions]

⚠️ Hey reviewer! BE CAREFUL ⚠️
Review the code before opening in your Gitpod. .gitpod.yaml was changed and it might be harmful.

[csweichel]

/werft run no-preview

👍 started the job as gitpod-build-cw-bump-leeway.33

[csweichel]

/approve

[akosyakov]

/lgtm
/approve no-issue

[roboquat]

LGTM label has been added.

Git tree hash: 268ef24c1baa555f218606f7139de1e3abab520f

[csweichel]

/assign @laushinka @mrsimonemms

[corneliusludmann]

/approve

[JanKoehnlein]

/lgtm

[roboquat]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: akosyakov, corneliusludmann, csweichel, JanKoehnlein

Associated issue requirement bypassed by: akosyakov

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JanKoehnlein,akosyakov,corneliusludmann,csweichel]
• components/gitpod-db/OWNERS [JanKoehnlein]
• components/supervisor/OWNERS [akosyakov]
• installer/OWNERS [corneliusludmann]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment