Defense-in-depth: verify Pod exists and is bound to TaskRun before signing

[vdemeester]

Summary

Add an optional safety check that verifies the referenced Pod exists and is bound to the TaskRun before signing. This is defense-in-depth against RBAC drift or misconfiguration — not a vulnerability fix.

Proposed behavior

When Chains processes a completed TaskRun:

1. Pod exists → verify ownerref/uid match with the TaskRun → proceed with signing ✅
2. Pod doesn't exist → log a warning + annotate with chains.tekton.dev/execution-verified: false → proceed with signing (non-blocking) ⚠️
3. Pod exists but doesn't match (wrong ownerref/uid) → this is the suspicious case → log error + annotate → optionally block signing based on config 🚫

Why non-blocking for missing pods?

Pods may be legitimately cleaned up before Chains processes the TaskRun:

• OpenShift and other platforms have pod GC / cleanup tooling
• Users may configure aggressive TTL-based cleanup
• Long-running Chains backlogs may process TaskRuns after pods are gone

Blocking on missing pods would break these real-world deployments. The annotation approach lets downstream consumers (policy engines, admission controllers) decide whether unverified execution is acceptable for their use case.

Implementation notes

• The check should be cheap — a single GET on the Pod, not a list/watch
• Consider making the behavior configurable: security.verify-pod-binding: warn (default) / block / off
• The "pod exists but doesn't match" case is the real red flag — this is harder to trigger accidentally

Context

Discussed in GHSA-p78q-4hg7-2hfp. @wlynch suggested this as "a cheap but good safety check to add." The reporter (@1seal) agreed this would help catch RBAC misconfigurations where taskruns/status write access drifts broader than intended.

Related: #1661 (trust model documentation)

/kind feature