fix: apply name references to kinds of unknown scope across namespaces

[jojinkb]

Fixes #5696

What happened

As reported (and reproduced by @stormqueen1990 at HEAD), a custom nameReference configuration stops being applied as soon as the referrer and the referral end up in different namespaces — for example when a NamespaceTransformer with unsetOnly: true moves the referral into one namespace while the referrer keeps its explicit namespace. The referral itself is renamed by namePrefix, but the field holding the back-reference silently keeps the old name, producing a dangling reference:

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: foo-test        # renamed by namePrefix
  namespace: bar        # set by the NamespaceTransformer
---
apiVersion: kuma.io/v1alpha1
kind: MeshMetric
metadata:
  labels:
    kuma.io/mesh: test  # NOT renamed -- dangling
  name: foo-test-metrics
  namespace: kuma

Root cause

Name-reference candidates are filtered by namespace twice: SubsetThatCouldBeReferencedByResource (api/resmap/reswrangler.go) and the sameCurrentNamespaceAsReferrer sieve in the nameref filter (api/filters/nameref/nameref.go). Both let a candidate through only if it shares the referrer's current namespace, or if it is known to be cluster-scoped per the openapi data (plus the RoleBinding/ServiceAccount special cases).

For kinds the openapi data doesn't cover — every custom resource, including the Mesh kind above, which is in fact cluster-scoped in its real API — kustomize guesses "namespace-scoped". That guess makes the namespace comparison meaningless, yet it was applied absolutely: any namespace mismatch (often introduced by kustomize's own namespace transformation) unconditionally suppressed the reference update, with no way to express the correct scope in a nameReference configuration.

The fix

When the strict same-namespace sieve leaves no candidates, fall back to the candidates whose kind's scope is unknown to the openapi data (openapi.IsNamespaceScoped not found), instead of silently dropping the reference. The existing disambiguation pipeline (prefix/suffix comparison, identity check, ambiguity error) still runs on the fallback set. SubsetThatCouldBeReferencedByResource is relaxed the same way so such candidates reach the filter at all.

Deliberately narrow consequences:

• Kinds whose scope is known from the openapi data (ConfigMap, Secret, ServiceAccount, ...) behave exactly as before; a new unit test pins that.
• A candidate in the referrer's namespace still always wins over cross-namespace candidates; a new unit test pins that too.
• The fallback only fires where current behavior is a guaranteed dangling reference (a renamed target whose referrer field is left holding the old name).

An alternative discussed in the issue was a new opt-in configuration field (e.g. allowedNs on nameReference entries). That requires extending the transformer-config API surface, and every user of a cluster-scoped custom resource would need to discover and set it; treating "scope unknown" as "namespace comparison unreliable" fixes the reported configurations without new API. Happy to rework in that direction if maintainers prefer the explicit knob.

Verification

• New failing-first regression test TestIssue5696NameReferenceWithNamespaceTransformer in api/krusty/namereference_test.go (the exact reproduction from the issue; fails at HEAD with kuma.io/mesh: test, passes with this change).
• New unit tests in api/filters/nameref/nameref_test.go covering: unknown-scope candidate in another namespace (updated), known namespaced kind in another namespace (still not updated), same-namespace candidate preferred over cross-namespace one.
• TestSubsetThatCouldBeReferencedByResource in api/resmap/reswrangler_test.go extended with an unknown-scope kind in an unrelated namespace, now expected in every referrer's subset.
• go test ./filters/nameref/ ./resmap/ ./internal/accumulator/ ./krusty/ in api/ passes.
• All three scenarios from the issue thread (NamespaceTransformer unsetOnly, namespace: + PatchTransformer, and the map-style gorillaRef example) now build with correct names and namespaces.

This change was developed with AI assistance (Claude Code); I have reviewed and tested it.

[kubernetes-prow]

Hi @jojinkb. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jojinkb
Once this PR has been reviewed and has the lgtm label, please assign koba1t 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