Artefact signatures, provenance, attestations

[ThomasVitale]

I'm starting this discussion to share ideas and gather feedback on how to reconcile emerging frameworks and standards for securing software supply chains and Cartographer.

Background material

• CNCF TAG Security - Software Supply Chain Best Practices
• Supply Chain Levels for Software Artifacts (SLSA)
• NIST Secure Software Development Framework (SSDF)

Current situation

At the moment, I can address some supply chain security concerns within the context of a specific resource. Cartographer doesn't know about what's going on within each resource.

• With kpack, using the Paketo Buildpacks, I get SBOMs automatically generated as part of the container image. I also have the possibility to have kpack sign a container image with cosign and push the signature to the same OCI registry as the image. Ultimately, I can deploy a service like Kyverno or Sigstore Policy Controller that we use to define some policies to verify the image signatures.
  • When using cosign with kpack, the private key should be granted to the service account used by the kpack Image resource. That would be the service account configured on the Workload resource in the developer namespace and then passed along to the Image resource by Cartographer. In order to ensure non-falsifiable artefacts, the private key should be available only to the build service. In the default setup, since the kpack builder Pod runs in the developer namespace, the private key would be exposed to developers. Any thoughts on this? It might be useful to provide some guidelines.
  • It's more of a consideration for the kpack project, but I'll share it here for context. I was considering how to take advantage of the SBOMs automatically generated by Buildpacks while also adopting a standard in-toto format to attest the SBOMs and allow clients to consume and verify the SBOMs in a standard way. Any thoughts on this?
• With Tekton, I can define some Tasks and wrap them in Runnables to scan source code or container images for vulnerabilities. For example, using Grype or Trivy. I might even use cosign again to sign the vulnerability report and perhaps even add an in-toto attestation to a container image following the cosign predicate spec for vulnerability scan reports.

Artefact signatures and attestations

A fundamental part of all three resources mentioned in the Background material section is the need for each stage in a supply chain to be able to trust+validate the input coming from a previous stage, and document+sign the produced output. That is in order to ensure integrity and non-falsifiable attestations.

The SLSA Framework defines the importance of generating Provenance data for each step of the supply chain to register information about the instance that ran the step, how it was triggered, what are the materials/dependencies used, what process was followed, and so on.

The in-toto attestation format is the recommended one to use to register such provenance data. And cosign can be used to sign and push the attestation to some storage.

In a nutshell:

• any output artefacts should be signed;
• for each step in the supply chain, provenance data should be generated, attested, and signed;
• signatures and attestations can be registered in a transparency log as well.

Brainstorming about Cartographer, signatures and attestations

One of the main features of Cartographer is that it provides a common abstraction to design supply chains. It take care of transferring inputs and outputs between the different supply chain resources without having to know the specific of what they are doing. That is an awesome feature to "glue" together different Kubernetes-native tools and design paths to production.

How do you see Cartographer in relation to the idea of supporting artefact signatures and attestations to secure supply chains? Since it deals with input and output data already, could Cartographer be the right place to implement a uniform strategy to achieve that rather than putting the responsibility on each resource?

If Cartographer is not the right place, what should the best practice or "reference architecture" be to define secure supply chains?

Prior art

Tekton has recently introduced a new project to deal with artefact signatures and attestations: Tekton Chains. From the official docs:

Tekton Chains is a Kubernetes Custom Resource Definition (CRD) controller that allows you to manage your supply chain security in Tekton.

In its default mode of operation, Chains works by observing all TaskRuns executions in your cluster. When TaskRuns complete, Chains takes a snapshot of them. Chains then converts this snapshot to one or more standard payload formats, signs them and stores them somewhere.

The SLSA project worked on a generic generator for GitHub Actions that can be used to generate different provenance metadata.