Add resolved top-level build config yaml to external parameters about chains HOT 11 CLOSED

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 of workflow, 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:

1. Use an object from the spec. ResourceDescriptor may do it?
2. 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.