Comments (11)
I agree with the thread above.
To give a bit more background, the challenge is that the SLSA Provenance v1 spec requires the builder to define the externalParameters
at exactly one level of abstraction, whereas here we effectively want to define it at more than one levels of abstraction:
flowchart LR
pipelineRef -- resolver --> buildConfigSource -- fetcher? --> pipelineSpec --> build;
params -.-> params2["params"] -.-> params3["params"] -.-> build;
- The raw
pipelineRef
/taskRef
input to Tekton, which matches the actual user input but is hard for policies to use because there is a level of indirection. - The resolved
buildConfigSource
git repo that is actually passed to the build process. This is more meaningful for policy engines but is arguably a resolved dependency. - The evaluated
pipelineSpec
.
The decision is to work around this by recording both externalParameters.runSpec.pipelineRef
and externalParameters.buildConfigSource
. This goes against the guidance that each external parameter should be independent but it seems like the least bad solution. The alternative of annotating resolvedDependencies
is harder to work with because it hide the fact that buildConfigSource
is an external parameter.
from chains.
I was thinking of this:
buildConfigSource:
ref: either git reference (i.e. commit sha - sha1:xxxx) or image digest (e.g. sha256:91fb5e20325059e8feb48c966a83d616596054c5edf811b5bc673683e6ecabb6)
repository: either git repository uri or image repository uri
path: either path in the git repo or the resource name in the image bundle.
from chains.
@lcarva agree with what you said. But I think this would be the option at the moment that is most aligned with recommendations from SLSA maintained build type. i.e. a structured field in externalParameters
We have talked to @MarkLodato about this issue, and Mark is working with the communities to define a standardized build type that is common across different build systems. Ideally, this way, verifiers won't need to have different verification logics for different builders.
I don't know what this generic build type will look like yet, but I suppose we would have a place (something like SLSA 0.2 predicate.invocation.ConfigSource) for the origin of build configuration b/c it is common information across different builders i.e. workflow for GitHub Actions, pipeline for Tekton PipelineRun and task for Tekton TaskRun.
from chains.
/kind feature
from chains.
Thanks @chitrangpatel !
The idea SGTM. Can you please be explicit about the extra field we want to introduce to the externalParameters? Is it just a single uri field, or is it an object containing key value pairs such as uri, digest and entryppoint? Also what names should we use for those fields?
from chains.
I like the idea for 2 reasons:
- Looking at Github Action (GHA) buildtype https://github.com/slsa-framework/github-actions-buildtypes/tree/main/workflow/v1#external-parameters, I think this is aligned with GHA overall. We just call the object
buildConfigSource
instead ofworkflow
, which makes sense because we don't have concept of workflow in tekton world. But subfields have same meaning and names. - Also having a designated field in externalParameters to capture the origin of this top level configuration might help provenance verifiers to verify this information, which follows SLSA suggestion - "values in externalParameters must be verified downstream". One good example: slsa-verifier is the actual verifier project that emphases/verifiers the source uri.
But I am curious what other folks think about this. cc @lcarva @wlynch
from chains.
Apologies for the late reply!
+1 for moving forward with this proposal. I just have some broader(?) questions about a potential gap.
If we're adding a custom object to externalParameters, doesn't that still make it so verifiers have to do something special for Tekton?
To avoid that, we would need to:
- Use an object from the spec. ResourceDescriptor may do it?
- Use a well known location to store this object. Given that
externalParameters
can store any object, this falls under convention instead of specification. But I don't think there's a better alternative.
from chains.
Thanks @MarkLodato for the inputs. That's helpful!
Just wonder if there is a link to the ticket/discussion in SLSA community about the generic CI/CD build type. That would help us follow up on the context and discussion and perhaps provide inputs as well.
Thanks so much!
from chains.
Hello 👋!
The implementation PR is ready for review: #863
from chains.
Closing since PR #863 has been merged.
from chains.
Here's the issue for a common CI/CD buildType: slsa-framework/slsa#940
from chains.
Related Issues (20)
- Add reload and/or restart functionality to Chains HOT 5
- Failure to connect to storage backends should fail readiness probe HOT 1
- Move tools.go to its own module
- Include the ServiceAccount running a pipeline in the chains provenance
- Index out of range error HOT 4
- ^ in MONGO_SERVER_URL password causes null pointer panic HOT 4
- Sigstore not working properly with `transparency.enabled: manual`
- in-toto Statement not compatible with previous versions
- Repeated subjects when using v2alpha4 and pipelineruns with deep-inspection enabled
- Wrong subjects returned when storing in grafeas
- Chains metrics HOT 1
- Promote SLSAv1.0 offering of Chains format to `beta` HOT 4
- Chains does not generate provenance for images built in a matrix HOT 7
- Archivista Backend HOT 1
- TestWatchBackend/verify_mongo-server-url-dir/MONGO_SERVER_URL_is_watched is buggy HOT 1
- Tekton Chains Controller is in "CrashLoopBackOff" due to "index out of range" error HOT 3
- test
- new test HOT 2
- panic using ed25519 signing key
- Signing key management HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chains.