docs(proposal): generic target-from resource dereference

[mloiseleur]

What does it do ?

Adds proposal 007: a generic external-dns.kubernetes.io/target-from annotation resolving a record's target from a field on another resource (dynamic client + RESTMapper, no vendor CRDs in sources).

Replaces per-product source-to-CRD coupling.

Motivation

Recurring, repeatedly-held/closed requests to couple sources to product CRDs: #6438 (Istio→Gateway API), #6190 / #6166 (→AWS Global Accelerator), #6457, #4687.

Formalizes the generic annotation @ivankatliarchuk sketched in #6190.

More

• Yes, this PR title follows Conventional Commits
• Yes, this is end user documentation

[kubernetes-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 vflaux for approval. For more information see the Code Review Process.

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

Details

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

[coveralls]

Coverage Report for CI Build 28705265521

Coverage remained the same at 83.384%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	21870
Covered Lines:	18236
Line Coverage:	83.38%
Coverage Strength:	1424.05 hits per line

---

💛 - Coveralls

[ivankatliarchuk]

I actually have branch with changes on my machine. Was experimenting with best possible options

[u-kai]

I like this proposal!

One concern: cross-namespace target-from references could introduce unexpected vulnerabilities. Worth considering something like Gateway API's ReferenceGrant for this?

[ivankatliarchuk]

On ReferenceGrant specifically: I'm not sure it fits the model external-dns operates under. Today, the referencer sets an annotation pointing at another resource - the referenced resource's owner has no say, for target, ingress, or any other lookup. That's not particular to this proposal; it's how the whole annotation-driven model already works. So the question isn't really "does this one feature need a grant mechanism" but "does external-dns's model need one at all" - given RBAC already governs what the controller can read.

There's already a Kubernetes-native mechanism for this: RBAC. Operators grant external-dns's ServiceAccount access to exactly the namespaces and resources they want it to read - that's the existing "who can point at what" boundary, and it already applies to every source in this codebase today.

On a possible --target-from-allowed-resources flag, I see it cutting both ways:

• Against: it works against least privilege. RBAC should be the single source of truth for what external-dns can access - not "the ServiceAccount has broad access, but the code additionally restricts itself to X and Y." Two places to reason about access is worse than one.
• For: from an implementation standpoint, an allowlist lets us load only the specific resources we care about into the cache, which is meaningfully more efficient than watching everything.

So if we do add something like new flag or CRD (ReferenceGrant), I'd frame it purely as a caching/efficiency knob, not a security boundary - RBAC already owns that job, and not clear why we should be introducing another abstraction.