Spike - Analyze how to use a product or service that implements the in-toto metadata standard in conjunction with GitLab Runner
Overview
- The purpose of this investigation spike is to determine if there is any development work required in Runner Core to seamlessly support generating provenance which is required for SLSA 2 using the in-toto framework.
Background
In this issue, we evaluated a customer developed solution, integrated into a fork of the Runner, that recorded an "attestation" in Grafeas at the end of the build step. Subsequent to that analysis the discussion for the overall GitLab strategy has shifted to focus on enabling SLSA 2 compliance with GitLab.
GitLab Runner design principles:
- The Runner does not integrate directly with other products or services. A few exceptions exist out of necessity (caching, Vault secrets).
- The rationale for not directly integrating is that we must absolutely support the same features across the board.
- The Runner must continue to be a simple job execution service that passes job execution data back to the associated GitLab instance.
Summary of analysis of customer developed solution:
- We're not sure integration with Runner is the best route. Runner mainly only talks to a GitLab instance and doesn't directly integrate with other products.
- Along with artifacts, we'd probably want to support adding evidence for packages and containers that we upload to Package Registry/Container Registry.
- To help figure out how to do this, we proposed adding support to the GitLab-Runner pipeline itself so we can figure out the pain points and pull in the right people to implement this.
- In addition, we've proposed extending Runner in a generic way, allowing hooks to be installed. We hope that this would help with anybody wanting to integrate such a solution with Runner, without modification of the Runner source code.
in-toto Metadata Framework overview
-
A software supply chain is the series of steps performed when writing, testing, packaging, and distributing software.
-
A typical software supply chain is composed of multiple steps “chained” together that transform (e.g., compilation) or verify the state (e.g., linting) of the project in order to drive it to a final product.
- Product example (in the case of GitLab Runner, we produce container images, binaries, rpm/deb packages.)
-
in-toto is designed to ensure the integrity of a software product from initiation to end-user installation. It does so by making it transparent to the user what steps were performed, by whom and in what order. In other words - the goal of the in-toto framework is to verify that each step in the software supply chain was carried out by authorized personnel only and that the final product was not tampered with.
-
Note the in-toto framework requires a project owner to create a layout. A layout lists the sequence of steps of the software supply chain, and the functionaries authorized to perform these steps.
Workflow diagram of the in-toto framework demo
Witness overview
- Witness is defined as a pluggable framework for supply chain security.
- The Witness attestation model at first glance seems like a simpler on-ramp to using a model based on the in-toto framework.
- Witness has defined two broad categories for attestors: PreRun and Internal.
- The attestor for GitLab pipelines is a Pre Run attestor.
Workflow diagram with TestifySec Witness for GitLab Attestor
{placeholder for workflow diagram}