Phase 5: OCI Containers Attestation (#20683) · Epics · GitLab.org

Phase 5: OCI Containers Attestation

## Executive Summary ### Problem to solve In phases 1 to 4 of [SLSA L3 Incremental Approach (#15858) · Epic · gitlab-org](https://gitlab.com/groups/gitlab-org/-/work_items/15858), we've created the code that allows for the generation of [SLSA Level 3 Provenance Attestations](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/slsa_level_3/) for artifacts. Phase 5 deals with the attestation of [container images in OCI registries](https://gitlab.com/gitlab-org/gitlab/-/work_items/583403). ### Proposal To make attestation of OCI Containers possible, we will: - Add the ability to attest OCI container images in the control plane. - Allow for the verification of these images with glab - Improve documentation to ensure usability for integrators. - Address bugs and feedback from previous phases, specifically error reporting and file size limits. More detail: [ADR 006: Enable the creation of SLSA Level 3 Attestations for OCI images](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/slsa_level_3/decisions/006_signing_with_sbom_and_provenance_in_oci/) ### High-level implementation plan 1. Refactor code related to attestations away from `PublishProvenanceService`. This code will be moved into its own abstraction, potentially located at `lib/supply_chain/artifact_provenance_publisher.rb` 2. Modify `SupplyChain::publish_provenance_for_build` to call `PublishProvenanceService` if the environment variables are present. 3. Implement attestation of containers within its own abstraction, `lib/supply_chain/container_provenance_publisher.rb`. 4. Document usage for attestation and verification. We're also looking to address bugs that are present in our current implementation: * A 5mb artifact file size limit currently exists. This should be increased. * When an attestation failure occurs, no errors are shown to the user, resulting in bad user experience. * An issue exists with `max_retries` within the Sidekiq worker that limits the maximum number of retries to 8. * `cosign` binary needs to be updated to the latest version. #### Breakdown * Milestone 1: * [Abstract attestation of artifacts out of PublishProvenanceService (\#588508) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/588508) * [Modify SupplyChain::publish\_provenance\_for\_build? method to check for ATTEST\_CONTAINER\_IMAGES (\#588509) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/588509) * [Add SLSA Attestation Generation Error to CI build UI (\#570341) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/570341) * [Upgrade \`cosign\` in CNG and Omnibus (\#588511) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/588511) * [Fix 5mb limit for artifact verification (\#588512) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/588512) * Milestone 2: * [Call \`cosign\` to attest OCI container images, persist \`.bundle\` (\#588510) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/588510) * [Bug: token expiry prevents successful retries after 8 attempts (\#588513) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/588513) * [Docs: Tidy up SLSA documentation (\#546180) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/546180) * Milestone 3: * [Discussion: Retention policy for SLSA attestations (\#559111) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/559111) * [Supply Chain Attestation E2E verification pipeline (\#578747) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/578747) * [Usage reporting metrics for attestation generation and verification (\#578742) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/578742) * [Follow-up: Address camelCase job details properties (\#584339) · Issue · gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/work_items/584339) #### Engineering Assessment This deliverable only requires ~backend resources. The main areas of scope will be: * `PublishProvenanceWorker`: ~backend changes required. * Attestations API: no change * Attestations UI: no change, small UX fix required * `glab`: no change #### Dependencies Epic dependencies: None Team dependencies: None #### Target/Metrics Implementation of this feature will enable customers to leverage attestation and signature verification as part of their workflows, furthering the work noted in [SLSA Level 3 Provenance Attestations](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/slsa_level_3/). This aligns with our longer-term goal of enabling SLSA compliance for our customers. Specific metrics for adoption are TBD and discussed in https://gitlab.com/gitlab-org/gitlab/-/issues/578742. #### DRIs - **DRI**: @sroque-worcel - **PM**: TBD - **EM**: TBD - **UX/PDM**: - **Group(s)**: ~"group::pipeline security" - **Engineering Owner**: @mmishaev - **GMP**: @ashalem #### Initiative Driver - Product or Engineering? - [x] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment - These initiatives require a Product Priority label (P1/P2/P3) - They may also receive GTM tier labels (T1/T2/T3) for external communication - [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components - These initiatives require an Engineering Priority label (E1/E2/E3) - They have internal visibility only and are not externally communicated - Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades #### Sizing and Funding (Optional) - **Size**: \[XS/S/M/L/XL\] - **Funding Status**: \[Funded/Partially funded/Not funded\] --- ### Hygiene Guidelines :bulb: \_See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/ ##### :one: Pre-Interlock - [ ] Update epic description with all relevant information - [x] Ensure all dependencies are identified - [ ] Apply appropriate labels (see below) - [ ] Apply target delivery Milestone - [ ] Update interlock status as discussions progress (via label) ##### :two: Post-Interlock: once quarter begins - Update health status weekly (via label) - Document any newly identified risks or dependencies - Link to implementation epics/issues as work begins - Flag any scope or timeline changes immediately

epic