Repository navigation
Add Pacto and Pacto Evidence material types #3367
Description
Hola Chainloop team!
I'd like to propose adding two native material types for Pacto:
PACTO— Pacto contractsPACTO_EVIDENCE— runtime evidence produced by Pacto
What is Pacto?
Pacto is an open-source contract system for cloud-native services. A Pacto contract is a machine-readable description of what a service is supposed to look like: ownership, interfaces, dependencies, configuration, workload, capabilities, etc. Contracts are versioned and distributed as OCI artifacts. For example:
pactoVersion: "2.0"
service:
name: payments
version: 2.3.0
owner:
team: payments
interfaces:
- name: api
type: openapi
ref: interfaces/openapi.yamlThe contract documentation has the full model.
The interesting part: runtime evidence
Pacto is not only about declaring the contract. Collectors observe the actual runtime and produce a common EvidenceSet. The Pacto evaluator then compares:
flowchart LR
C[Pacto Contract] --> E[Pacto Evaluator]
X[Runtime] --> K[Pacto Collector]
K --> ES[EvidenceSet]
ES --> E
E --> F[Findings]
The important bit for this proposal is that Pacto can now persist that evidence as a content-addressed OCI artifact (see evidence OCI storage and collectors for the details). So we now have two different OCI artifacts:
flowchart LR
C[Pacto Contract] --> O1[OCI Artifact]
E[Pacto Evidence] --> O2[OCI Artifact]
Why Chainloop?
This looks like a natural fit for Chainloop's material model. A release could contain:
flowchart TD
R[Release] --> I[Container Image]
R --> S[SBOM]
R --> P[Provenance]
R --> C[PACTO]
R --> E[PACTO_EVIDENCE]
This gives Chainloop a way to connect the usual software supply-chain artifacts with runtime information about the service. For example, a PACTO_EVIDENCE artifact can reference the exact Pacto contract it was collected against by digest. This makes it possible to establish:
this runtime evidence was collected for this exact contract.
And Chainloop can then apply its own policies to the attestation, for example:
- a production release must contain a Pacto contract;
- it must contain Pacto runtime evidence;
- the evidence must reference the same contract digest;
- the evidence must not be stale.
Those are Chainloop-level policies. Pacto remains responsible for interpreting the contract and evidence and producing its own findings.
Proposed material types
I think the initial implementation could be quite small:
PACTO
Accept a Pacto OCI artifact and expose basic metadata such as:
- service name/version
- owner
- Pacto version
- digest
PACTO_EVIDENCE
Accept a Pacto Evidence OCI artifact and expose:
- subject/service
- contract digest
- collector/source
- observation timestamp
- evidence digest
The underlying artifacts should remain content-addressed and be handled through Chainloop's existing material/CAS mechanisms.
The existing generic EVIDENCE material type could technically be used for this, but I think Pacto is a good candidate for a native type because both the contract and evidence have a defined format and semantics, and the relationship between the two is important.
References
- Pacto
- Pacto architecture
- Pacto collectors
- Pacto Evidence OCI storage
- Chainloop material types
- Chainloop policies
Happy to contribute the Pacto side and work with the Chainloop team on the material type implementation.
Activity