Road to SLSA3: Non-falsifiable Provenance in Tekton with SPIFFE/SPIRE

The presentation discusses the challenges of locking down Providence metadata fields in Tecton and proposes a solution using Spiffy Inspire for strong attestation and verification.

• Tecton users have direct access to objects and metadata fields, making it difficult to lock down Providence metadata fields
• Kubernetes cluster classes are managed by different entities, making it challenging to restrict access to metadata fields
• The Task Run object becomes a main attack point for malicious actors
• The proposed solution involves creating a trusted computing base and restricting access to metadata fields
• Spiffy Inspire provides strong attestation and verification for the trusted computing base
• Future work includes extending the solution to other custom resources and validating artifacts passed between tasks

The presenter explains that a malicious actor could modify the hash of an artifact being produced, creating provenance for another artifact that wasn't actually being built. The proposed solution involves signing and verifying the fields produced by the trusted computing base, which would detect any unauthorized changes.

Tekton, a cloud native solution for building CI/CD systems, has made great strides in achieving SLSA Level 1 (​​unsigned provenance) and 2 (hosted source/build, signed provenance) with the inclusion of Tekton Chains. Part of attaining higher SLSA levels include protecting and holding the build systems we use accountable. A requirement of SLSA level 3 is non-falsifiable provenance, which states that build system provenance should not be falsifiable by build service’s users - i.e. protecting against cluster administrators. With the integration SPIFFE/SPIRE, Tekton can achieve this capability. SPIFFE/SPIRE provides Tekton with short-lived certificates (backed by workload attestation), that are used to sign build results and status updates (through the TaskRun object). This results in the ability to provide and verify provenance of the build steps, ensuring that they are cryptographically protected against edits not performed by the Tekton Trusted Computing Base (TCB). In this presentation we will show this in action and sabotage our own pipelines to visualize non-falsifiable provenance.