Harden DCR resolver against SSRF when operator trust boundary changes

[tgrunnagle]

Context

Raised by code review on #5042 (comment).

DCRUpstreamConfig.DiscoveryURL and DCRUpstreamConfig.RegistrationEndpoint are operator-supplied URLs validated only for HTTPS-or-loopback. There is no allowlist or RFC1918 / link-local / metadata-service guard. The resolveDCRCredentials resolver issues outbound requests to whatever the operator configures — possibly with the RFC 7591 initial access token attached.

Today the operator role is fully trusted, so this is acceptable. The runtime trust assumption is now documented on DCRUpstreamConfig itself (see pkg/authserver/config.go).

When this becomes a problem

If the trust boundary ever changes — e.g.:

• A multi-tenant operator deployment where a tenant role can populate DCRConfig.
• Federated CRD authoring across less-trusted namespaces.
• A future surface that lets less-privileged roles supply DCR fields.

…then the resolver becomes a confused-deputy: an attacker who can write to the field can coerce the authserver into making outbound requests to internal addresses (cloud-provider metadata services, RFC1918 ranges, link-local 169.254.169.254, etc.), with the bearer token attached.

Hardening options

1. Block RFC1918 / loopback (when not explicitly opted in) / link-local / cloud metadata addresses at validation time. pkg/networking.IsPrivateIP already exists.
2. Operator-level allowlist of permitted DCR hosts.
3. Egress-controller / network-policy approach (out-of-process).

Acceptance

• DCR resolver rejects URLs resolving to private / link-local / metadata-service addresses unless explicit opt-in.
• Loopback-for-development carve-out preserved (existing behavior).
• Documented in DCRUpstreamConfig doc comment, replacing the trust-assumption note.