Reduce number of annotations Chains stores in CRD objects

[wlynch]

Feature request

It could be useful to add flags to reduce the # of annotations in CRD objects so we don't push etcd object limits.

cert trust roots should generally be loaded out of band for verification, so chains.tekton.dev/cert and chains.tekton.dev/chain aren’t really needed (but are useful for debugging).

chains.tekton.dev/payload could be removed if we could deterministically reconstruct it later. We’d need information like what version of chains generated the provenance in it’s place.

Use case

See https://tektoncd.slack.com/archives/C015FAQV290/p1710249674292949

[anithapriyanatarajan]

@wlynch, Could you help with further details on this issue. As per initial analysis, apart from the following standard annotations: chains.tekton.dev/signed chains.tekton.dev/retries chains.tekton.dev/transparency Additional annotations are added to taskrun CRD if the storage backend for taskrun artifacts.taskrun.storage is defaulted to tekton. Similar should be the case for pipelinerun. List of additional annotations only in scenario where the storage backend is tekton itself: chains.tekton.dev/payload-%s" chains.tekton.dev/signature-<tr/prid> chains.tekton.dev/cert-<tr/pr id> chains.tekton.dev/chain-<tr/pr id>

Below is the approach we could take:

1. chains.tekton.dev/retries - could be managed from configmap (chains-config)
2. chains.tekton.dev/transparency - could be managed from configmap (chains-config)

In a case where the storage type is tekton( The intention of which i assume is to use an inbuilt cluster storage) - we could design a new CR to capture the key values as new CR specs.

Please add your views and any additional items to be considered

[anithapriyanatarajan]

@wlynch I hope this is a concern only if the storage backend is tekton. such a config is NOT RECOMMENDED for production use. Do we still need this feature?