Keep a membership's or grant's team reference inside the github-config namespace

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

Found by the independent review of #4524. The membership and repository-grant rules in restrict-github-team-management require spec.forProvider.teamIdRef.name to be admins or maintainers, on the assumption that the name refers to the Team object in github-config. The provider's reference type also has a namespace field (v0.20.0 CRD), and no rule looks at it. A fixture with teamIdRef: {name: admins, namespace: <another namespace>} passes every team rule under kyverno test.

Not yet verified: whether the provider's reference resolver honours that field for these kinds, and whether a Team object named admins could exist in another namespace that the provider reconciles.

Problem and audience

If the resolver honours it, the allow-listed name stops being a faithful stand-in for the approved team: the reference could resolve to a Team object the team rules never judged. The audience is the maintainer, who relies on these rules to bound the delegated release.

Expected behaviour

A membership or grant in github-config can only reference a Team object in github-config.

Acceptance criteria

• The resolver's behaviour is established first, from the released source of the provider version production runs.
• If the field is honoured, teamIdRef.namespace (under forProvider and initProvider) may only be unset or github-config, compared literally, with fixtures that fail without the rule.
• If it is not honoured, the reason is recorded here and the issue closed.

Same file as #4517; doing both in one change is reasonable.

[devantler]

🤖 Generated by the Agentic Engineer

Criterion 1 established: the field is honoured. Read from the released source of what production runs (provider-upjet-github v0.20.0, which builds on crossplane-runtime v2.1.0):

• The provider's generated resolvers for TeamMembership and TeamRepository use the namespaced resolver (apis/namespaced/team/v1alpha1/zz_generated.resolvers.go).
• That resolver reads the referenced object from the reference's own namespace when one is set, and only falls back to the referring object's namespace when it is empty (pkg/reference/namespaced_reference.go, the Resolve function).

So the second criterion applies: the rule is needed. What limits the exposure today is that a Team object would have to exist in another namespace, and only the github-config release is granted this API group; the admission rules should not depend on that.

The change touches the same file as #4519 (open) and #4517, so it is best made after #4519 merges, together with #4517.

[devantler]

🤖 Generated by the Agentic Engineer

Delivered and verified live

• Criterion 1 was established on 2026-10-05 (comment above): the provider honours the field.
• Criterion 2 was delivered by fix(github-config): compare tenant-written text literally in the team rules #4526, merged 2026-10-06 09:57Z (f28ac8ddc99461cee3c51e3e15c4d2e2ec93bf4b), with fixtures that fail without the rule. That pull request links Compare tenant-written text literally in the GitHub team admission rules #4517, so this issue was left to close by hand.
• Read back from production at 10:17Z (read-only): the restrict-github-team-management policy is Ready, and both reference rules — the membership rule and the repository-grant rule — are in Enforce and carry the namespace condition for forProvider and initProvider. The condition is a literal list of two allowed values, unset or github-config, not a pattern match.

A membership or grant in github-config can therefore only reference a Team object in github-config. Closing.