The default builderID needs to be changed.

[chuangw6]

Background

One important field in SLSA provenance is predicate.builder.builderID.

Chains does support setting this value via the configmap field named builder.id, which is great and we'd like to keep this. But the default builderID https://tekton.dev/chains/v2 set here sounds not right.

Expected Behavior

Chains has correct default value for the builder id.

Actual Behavior

The default value used by Chains is https://tekton.dev/chains/v2. It doesn't make sense because Chains apparently is not the builder and doesn't contribute to the artifact build.

[wlynch]

We may want to derive this value from the run status itself so the controller can self-report - either by app.kubernetes.io/managed-by, ManagedFieldsEntry or some other mechanism.

[lcarva]

Builder is defined as:

Identifies the entity that executed the invocation, which is trusted to have correctly performed the operation and populated this provenance.

I'm wondering if Tekton Chains is the correct value for builder. Isn't the builder actually Tekton Pipelines? It seems to fit the definition more accurately. The only exception being "populated this provenance", but, arguably, Tekton Pipelines does play an important role here as well.

[chuangw6]

I'm wondering if Tekton Chains is the correct value for builder. Isn't the builder actually Tekton Pipelines? It seems to fit the definition more accurately. The only exception being "populated this provenance", but, arguably, Tekton Pipelines does play an important role here as well.

Yeah, that's a good call. I feel like thinking of Chains as a plugin/helper of Tekton Pipeline to assist in populating the provenance might help reconcile ourselves XD hahah.

+1 to @wlynch 's idea.
We might want to handle this builderID in a similar way as component versions. The goal is to avoid information/version drift by making info available as part of installing Tekton and letting chains just pick up from CRD itself instead of configmap.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[lcarva]

/lifecycle frozen

There's some interest in resolving this relatively soon.

[lcarva]

@wlynch mentioned in slack today that keeping the ability to set the builder ID via config could be misused as a spoofing technique.

We should clarify that before working on this issue.

A spoofing attack would mean a certain Chains deployment can identify itself as a another Chains deployment. In order to do that successfully, the Chains deployment would also have to use the same signing key (or cert issuer/subject in keyless). If that happens, the builder ID is the least of your problems.

We should also keep in mind the upcoming v1.0 SLSA Provenance spec which has some very specific requirements for this attribute:

URI indicating the transitive closure of the trusted build platform. This is intended to be the sole determiner of the SLSA Build level.

If a build platform has multiple modes of operations that have differing security attributes or SLSA Build levels, each mode MUST have a different builder.id and SHOULD have a different signer identity. This is to minimize the risk that a less secure mode compromises a more secure one.

The builder.id URI SHOULD resolve to documentation explaining:

• The scope of what this ID represents.
• The claimed SLSA Build level.
• The accuracy and completeness guarantees of the fields in the provenance.
• Any fields that are generated by the tenant-controlled build process and not verified by the trusted control plane, except for the subject.
• The interpretation of any extension fields.