Document Chains trust model for multi-tenant deployments
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 277
- Forks
- 164
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 61
Description
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:
- 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.
taskruns/statusis the critical RBAC boundary — anyone withupdateontaskruns/statuscan influence what Chains signs. In standard Tekton RBAC, only thetekton-pipelines-controllerandtekton-chains-controllerClusterRoles have this permission.- 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.
- TaskRun results are user-controlled — results like
IMAGE_URLandIMAGE_DIGESTare 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/statusprotection - Recommend
storage.oci.repositoryas 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No documentation file is named; first locate the existing Chains deployment or security documentation and read its current RBAC and storage guidance. Add a Trust Model section covering TaskRun status, task authorship, OCI storage, and SLSA trust boundaries, then verify that all requested operator recommendations are addressed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- documentation, security
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 62/100