[go: up one dir, main page]
Skip to content

Architectural Decision: Where do we generate SLSA provenance?

Context

Today SLSA 1.0 provenance statements are generated by helpers of the GitLab Runner. See https://docs.gitlab.com/ci/runners/configure_runners/#artifact-provenance-metadata

As part of #514814 (closed) we're implementing a CI/CD component that generates SLSA provenance attestations. That component reuses the SLSA provenance statement produced by the runner helper.

What currently exists and what we're implementing (CI/CD component) might not be the best options for provenance statement generation. We want to explore other options, and select the best one.

Options

SLSA provenance statements could be generated in the following components:

  • Runner helper (current implementation)
  • Runner – is that even possible?
  • GitLab backend
  • an entirely new service

Note: This list can be updated with other options identified when solving this issue.

Criteria

Requirements

  • air gap support
  • meets SLSA requirements for L3
    • Is it in the control plane?
  • provides complete SLSA provenance
    • repository URL and commit SHA
    • build ID
    • runner ID
    • CI/CD variables
  • provides artifact digest
  • can handle the load (computational cost is low)
  • can connect to a signing component in a secure way (if not the signing component itself)

Aspects to be considered when comparing options:

  • infrastructure complexity
  • maintenance complexity
  • integration effort (no need for external library)
  • development effort
  • familiarity with component and its tech stack
  • alignment with architecture
  • security boundary
  • scalability (computational cost is low)

See https://slsa.dev/spec/v1.0/requirements

Accuracy: The provenance MUST be generated by the control plane (i.e. within the trust boundary identified in the provenance) and not by a tenant of the build platform (i.e. outside the trust boundary), except as noted below.

Every field in the provenance MUST be generated or verified by the build platform in a trusted control plane.

Tasks

  • Evaluate options (discuss in issue)
  • Make decision (discuss in issue)
  • Capture context, options, decision, and consequence in ADR (open MR)
  • Update design doc with decision, and link it to ADR (open MR)

Decision needs to be added to https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/slsa_level_3/#decisions

/cc @darbyfrey

Edited by Fabien Catteau