Run release process in-cluster (automated signing)

[vdemeester]

Summary

Move the release process (hack/release.sh) to run in-cluster (e.g. as a GitHub Actions workflow or Tekton Pipeline) so that the signing key doesn't need to be stored locally.

Current state

Today, releases are done locally:

./hack/release.sh v1.5.0 --llm

This requires the developer to run the script locally. For task signing (TEP-0091 / tekton.dev/signature), this would also require an ECDSA private key on the developer's machine.

The script:

1. Bumps versions and changelog
2. Commits, tags, and pushes
3. The tag triggers the release workflow which publishes bundles to ghcr.io, signs them with cosign, and builds the git-init image with goreleaser

Goal

Move the full release process (including Tekton Trusted Resources signing) to CI so that:

• No developer needs the private key locally
• Signing is automated and auditable
• The release is fully reproducible

Options

Option A: GitHub Actions release workflow

• Store the signing key as a GitHub secret (SIGNING_KEY)
• A workflow triggered by a tag (or manual dispatch with version input) runs the full release:
  version bump → tkn task sign → commit → bundle push → cosign sign → goreleaser
• Requires tkn CLI in the workflow (already have setup-tektoncd-cli action)

Option B: Tekton Pipeline (dogfooding)

• Run the release as a Tekton PipelineRun on a cluster
• Signing key stored as a Kubernetes Secret
• Uses tkn CLI task for signing
• True dogfooding of the catalog

Option C: KMS-based signing

• Use a cloud KMS (GCP, AWS, Azure, Vault) instead of a file-based key
• tkn task sign supports KMS via the -m flag:

  tkn task sign task.yaml -m=gcpkms://projects/PROJECT/locations/LOCATION/keyRings/KEYRING/cryptoKeys/KEY

• Most secure, no key material to manage

Recommendation

Start with Option A (simplest, already have the workflow infrastructure), with a path to Option C for production use.

Related

• Run release process in-cluster (automated signing) golang#23 — same issue for the golang catalog
• TEP-0091: Trusted Resources

Checklist

• Add tkn task sign to the release process
• Choose key storage approach
• Update release workflow to handle full release (not just bundle publish)
• Store public key in repo for user verification
• Document the new release process

[vdemeester]

Update: keyless signing status

Investigation shows that keyless/Fulcio signing is not yet supported for Tekton Trusted Resources:

• TEP-0091 designed a Keyless field on Authority with KeylessRef (Fulcio URL + identities + CA cert) — see TEP-0091 L341-373
• However, it was never implemented — the current VerificationPolicy CRD only supports key (secretRef, data, KMS), not keyless
• tkn task sign only supports -K (key file) and -m (KMS), no keyless option
• The TEP explicitly says Fulcio integration is "future work"

Filed upstream: tektoncd/pipeline#TBD

Decision: per-repo ECDSA keys

Until keyless lands upstream, we use per-repo ECDSA signing keys:

• Private key: stored as GitHub secret (for CI) or locally (for manual releases)
• Public key: committed to keys/cosign.pub in the repo
• Users verify with: tkn task verify task.yaml -K=keys/cosign.pub

Two layers of signing

Layer	Method	Keyless?
OCI bundles (ghcr.io)	cosign in GitHub Actions	✅ Yes (GitHub OIDC)
YAML manifests (tekton.dev/signature)	tkn task sign	❌ Key required

[vdemeester]

Upstream issue filed: tektoncd/pipeline#10189