Document Chains trust model for multi-tenant deployments

[vdemeester]

Summary

Chains trusts TaskRun status as set by the Tekton Pipeline controller. This is the intended trust boundary, but it's not explicitly documented. Operators deploying Chains in multi-tenant environments need to understand:

1. Chains is a post-execution observer — it signs completed TaskRuns without re-validating execution. The Pipeline controller and Kubernetes RBAC are responsible for ensuring TaskRun status reflects actual execution.
2. taskruns/status is the critical RBAC boundary — anyone with update on taskruns/status can influence what Chains signs. In standard Tekton RBAC, only the tekton-pipelines-controller and tekton-chains-controller ClusterRoles have this permission.
3. Chains is a signing oracle whose output crosses the cluster trust boundary — signed provenance is consumed by external policy engines, admission controllers, and verification pipelines. Operators must ensure the RBAC boundary is tight.
4. TaskRun results are user-controlled — results like IMAGE_URL and IMAGE_DIGEST are set by Tasks and flow into SLSA provenance subjects. In multi-tenant setups where Task authors are untrusted, operators should use curated Task catalogs and restrict Task authorship via RBAC.

What to document

• Add a "Trust Model" or "Security Model" section to the docs
• Explain the RBAC requirements for taskruns/status protection
• Recommend storage.oci.repository as a security-critical config for multi-tenant OCI storage deployments
• Clarify that SLSA Build L1-L2 trusts the build platform, not end-to-end content verification

Context

This came from security advisory triage (GHSA-p78q-4hg7-2hfp) where the reporter and maintainers agreed the trust model is correct but under-documented. The "signing oracle whose output crosses the cluster trust boundary" framing (credit: @1seal) is a useful way to explain why the RBAC boundary matters.

/kind documentation