(feat)Support native Tekton Artifacts API in SLSA provenance - #1841
(feat)Support native Tekton Artifacts API in SLSA provenance#1841ngelman1 wants to merge 1 commit into
Conversation
tekton-robot
added
the
size/XL
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1841 +/- ##
==========================================
+ Coverage 61.98% 62.50% +0.51%
==========================================
Files 64 64
Lines 4067 4155 +88
==========================================
+ Hits 2521 2597 +76
- Misses 1265 1272 +7
- Partials 281 286 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
60566c4 to
eca4358
Compare
|
/assign |
| return objs | ||
| } | ||
|
|
||
| // ExtractOCIImagesFromArtifacts extracts OCI image references from native Tekton Artifacts (TEP-0147) outputs where BuildOutput is true. |
There was a problem hiding this comment.
TEP-0147’s buildOutput flag selects subject versus byProduct; it is not an OCI media-type marker. The API explicitly supports packages, reports, source artifacts, and purl URIs. Recommended forms such as pkg:docker/... fail this parser, while some non-OCI URI forms can be accepted as registry references. Could we avoid feeding every build output into OCIArtifact, or require a reliable OCI-specific signal first?
There was a problem hiding this comment.
youre right. this adds more noise than use, removing this.
native artifacts still map correctly into provenance subjects via subjectsFromNativeArtifacts
| addArtifactOutputs(arts.Outputs) | ||
| } | ||
|
|
||
| for _, step := range obj.GetStepArtifacts() { |
There was a problem hiding this comment.
Pipeline retains step artifacts in Status.Steps[].Outputs and also merges them into Status.Artifacts.Outputs. Walking both collections therefore emits duplicate signable objects; I reproduced two objects for one artifact. Please consume the aggregate once, with a step-level fallback if it is absent, or deduplicate by canonical digest.
| } | ||
| } | ||
|
|
||
| for _, step := range tro.GetStepArtifacts() { |
There was a problem hiding this comment.
Pipeline also supports task-level artifacts written through $(artifacts.path). Those appear in Status.Artifacts but not under an individual step, so this loop omits their non-build outputs from byProducts; I reproduced zero byproducts for one such output. Please read the aggregate here, with a step-level fallback if needed.
There was a problem hiding this comment.
ok added. not sure I understand why we need the fallback though..? if an artifact appears in a step, than it will always appear in Status.Artifacts , correct? in what scenario is Status.Artifacts` empty but we still have step level artifacts?
| t.Error("expected at least one subject in the provenance statement") | ||
| } | ||
|
|
||
| if signedTR.Status.Artifacts != nil { |
There was a problem hiding this comment.
This test can pass without producing any native artifact. The fixture writes only the legacy IMAGE_URL/IMAGE_DIGEST results, never writes $(step.artifacts.path), and this test does not arrange for enable-artifacts to be enabled. Consequently, artifacts may be nil and skipped or non-nil but empty, while the legacy results satisfy the subject assertion. Please emit native input, build-output, and non-build-output artifacts and assert their exact URIs and digests in resolvedDependencies, subjects, and byProducts.
| ### How it works: | ||
| Instead of writing to specially named results, steps write a structured JSON file to $(step.artifacts.path). The Tekton Pipelines controller reads this file and populates status.artifacts and status.steps[].inputs/outputs on the TaskRun. | ||
|
|
||
| Chains then maps these artifacts into the SLSA provenance. |
There was a problem hiding this comment.
Could we scope this documentation and the release note to slsa/v2alpha4? Native subject and byproduct handling is currently wired only into that formatter. Native inputs also reach v2alpha3 through the shared resolved-dependency code, but its outputs do not, and the default in-toto format and slsa/v1 receive neither.
| taskSpec: | ||
| steps: | ||
| - name: build-and-push | ||
| image: gcr.io/kaniko-project/executor |
There was a problem hiding this comment.
This example cannot run with the selected image: the Kaniko executor image contains neither bash nor buildah. Also, Buildah writes --digestfile as algorithm:hex, so placing ${DIGEST} under the sha256 key produces sha256:sha256:.... Please use a compatible image and strip the prefix, for example ${DIGEST#sha256:}.
| } | ||
| EOF | ||
| ``` | ||
| If a TaskRun uses both type hinting and native artifacts, Chains will include artifacts from both sources. Duplicates are removed automatically. |
There was a problem hiding this comment.
“Duplicates are removed automatically” is currently true only for subjects and resolved dependencies. OCI extraction duplicates step artifacts through aggregate and per-step status, while byproducts have no deduplication. Please qualify this statement or deduplicate every affected path.
Wire the native Tekton Artifacts API (TEP-0147) into Chains' SLSA provenance generation so that structured artifact declarations from TaskRun status are included in the attestation alongside the existing type-hinted results. - Add GetArtifacts/GetStepArtifacts to TektonObject interface - Extract OCI images from native artifact outputs for signing - Map artifact inputs to resolvedDependencies - Map buildOutput=true outputs to SLSA subjects - Map buildOutput=false outputs to SLSA byproducts - Add unit tests for all new functions - Add e2e test for native artifacts provenance
eca4358 to
09be1b2
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
5 participants
Changes
Today, Chains generates SLSA provenance for TaskRuns by extracting input and output artifacts from type-hinted results -specially named results like *IMAGE_URL, *IMAGE_DIGEST, CHAINS-GIT_COMMIT, and *ARTIFACT_OUTPUTS. If a result name doesn't match the expected pattern, Chains silently ignores it.
This PR is wiring the Tekton native artifact API (TEP-0147) into Chains' SLSA provenance generation.
This allows steps to explicitly declare their inputs and outputs by writing a JSON file to $(step.artifacts.path). The Pipelines controller then populates
status.artifactsandstatus.steps[].inputs/outputson the TaskRun with structured data including URIs, digests, and a buildOutput flag.Artifact mapping
buildOutputinputs[].valuesresolvedDependenciesoutputs[].valuestruesubjectoutputs[].valuesfalsebyproductsThis does not replace type-hinting, but adds the ability of chains to fetch inputs and outputs, without forcing the user to exactly match naming convetions.
**Tested on a kind cluster
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes