Add design for trust source plugins

[SgtCoDFish]

Follows discussion in standup on 2025-07-16

[cert-manager-prow]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cert-manager-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign maelvls for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ThatsMrTalbot]

To avoid object size limits I would have the status expose an array of secrets that contain the actual bundle, most implementations would probably only ever need a single secret, but cant hurt to future proof it in the design.

Something like:

status:
  bundleSecrets:
  - name: example-bundle-01
  - name: example-bundle-02

For namespaced sources the secrets would exist in the same namespace as the resource, for cluster sources the secrets would exist in the trust-manager namespace

[erikgb]

If any source exceeds the size limit, the targets will also exceed the size limit. I don't think we need to account for this additional complexity.

[ThatsMrTalbot]

IIRC we have had issues raised in the past about peoples bundles exceeding the size, I would argue that is where a CSI driver could help 🙂

I also wonder if post-quantum will increase CA cert size enough to make hitting the 1mb limit more likely

[ThatsMrTalbot]

1. If a source produces a bundle larger than 1mb then it will need to shard it across multiple secrets, you would need to know that to include all the shards in your trust bundle. By referencing the CRD you get a single object you can reference
2. It gives us the option of having cluster scope sources, if you just reference secrets you can never have a namespaced TrustBundle reference anything outside its own namespace. I think cluster scope sources would be a great way for us to ship our "default" CAs with a ClusterImageTrustSource
3. I think its better UX. If you used secrets then a ImageTrustSource would ether need to produce a deterministic secret name or have a configurable secret name, and IMO the secret is just an implementation detail.

[ThatsMrTalbot]

The controller-runtime uses a dynamic discovery implementation, so CRDs do not need to be installed first.

[ThatsMrTalbot]

This is a good point, probably yes

[ThatsMrTalbot]

I would not have it configurable, I would have a "contract" we have with plugins that says you must have this field to function. That is how ClusterAPI works for example, the providers have their own CRDs that work with ClusterAPI if they fulfil the API contract.