Support Multiple Signatures in Tekton Chains

[anithapriyanatarajan]

Feature request

Currently, Tekton Chains supports a single global signing configuration (e.g., a cosign key or keyless setup) per controller instance. This means all artifacts signed by Chains use the same signing identity, regardless of namespace, pipeline, or tenant.

This request proposes support for multiple signing configurations and a mechanism to select which signature to use based on context — for example:

• Namespace-specific configurations
• Pipeline- or TaskRun-level annotations
• Explicit reference to a named signature configuration

Usecase

In many deployments, multiple teams share the same Tekton infrastructure. These teams:

• Own and manage their own CI/CD pipelines
• Require independent trust boundaries
• Need to sign their own artifacts using their own keys

A single signing key per cluster doesn't accommodate these needs. Supporting multiple signatures enables:

• Better isolation and security
• Clearer trust scopes for downstream verification
• Support for multi-tenant CI/CD workflows

[lcarva]

@anithapriyanatarajan, given that you can run an instance of Chains to only watch certain namespaces, it should be possible, in theory, to run multiple instances of Chains on the same cluster watching different sets of namespaces.

I do think that does provide a better isolation of "environment". For one, a certain Chains controller instance would only need read access to the Secrets on its limited set of namespaces.

The downside of this approach is that running multiple instances of the controller will have a larger footprint on the cluster.

Have you considered this approach?

[anithapriyanatarajan]

@lcarva - Thanks for suggesting this approach. I did not consider this. Will assess this approach and share the ouctome here for further discussion. Thanks again.

[anithapriyanatarajan]

I would like to add another perspective to the issue.

Tekton Chains should support the following, if the user intends to:

Configurable Skipping of Artifact Signing - Chains should allow artifact signing ( container images) to be disabled. Right now we are enabling default signing of images. We could set a configuration option that conveys the chains controller to skip artifact signing in all cases for specific namespaces.

In this mode, Tekton Chains should still:

• Generate build provenance (TaskRun / PipelineRun attestations)
• Sign the attestations
• Publish them using the configured backends

User-Managed Artifact Signing Inside Pipelines

Users should be able to handle artifact signing within the pipeline itself, using:
Custom Tasks (e.g., sign-artifact)
Secrets managed through Vault, Kubernetes Secrets, or KMS integrations
Any signing tool appropriate to their environment, including: cosign or gpg or Enterprise signing clients or APIs

This approach maintains SLSA-compliant build attestations via Chains, while giving users full control over artifact signing strategies.

The issue I see without this skip feature is, since we do not have the option to override chains to skip the signing, the images might by signed by default which constraints the user from choosing different signing for different repos

@lcarva @vdemeester @jkhelil - Please share your views to introduce the option to skip chains ARTIFACT signing alone if the PR/TR/Namespace is annotated to do with annotation like "chains.tekton.dev/artifacts-signing: "override"

[lcarva]

@anithapriyanatarajan, this is possible to day by setting artifacts.oci.storage to an empty string. (It's a bit odd UX but I have used it in the past.) We can make this nicer, or at least document it.

Long-term, I'd like the image signing functionality to be removed from Chains altogether: #1346.

[anithapriyanatarajan]

@lcarva Thankyou again for connecting the dots and guiding more clarity on this issue.

While we could completely deprecate image signing at a later stage, to start with I would like to incorporate a config option artifacts.oci.disablesiging of type bool that allows the user to disable Image signing alone with Chains while the rest of SLSA mandates to generate provenance and attest PR/TR continues to be the same.

This would address:

tektoncd/chains#1406: Allow users to opt out of Chains-enforced signing and choose alternative signing workflows (per PipelineRun, per namespace, or other custom logic through parametrized PR/TR definitions).

tektoncd/chains#1346: Provide a clean way to decouple provenance/attestation generation from image signing without disabling Chains entirely.

If you are convinced I could submit a PR for this. cc: @arewm

[lcarva]

👍 Looking forward to the PR!

[arewm]

I think that definitely makes sense! Then #1346 would become more a question of what the configuration value should be by default?

[waveywaves]

/assign
taking this up as discussed with @anithapriyanatarajan last week