api: Enables the binding of APIs in protected groups

[astefanutti]

Summary

This PR enables the binding of APIs whose groups are protected, as defined in kubernetes/enhancements#1111.

The proposed solution delegates to the user the responsibility of adding the api-approved.kubernetes.io annotation to the APIResourceSchema resource, as for standard CRDs, so it makes it explicit, and prevents from accidentally declaring APIs in a protected group. With this PR, the APIBinding controller will simply propagate the annotation to the projected CRDs.

In the API import case, where CRDs are generated following the creation of APIResourceImport resources, the NegociatedAPIResource controller already adds the approval annotation, assuming the API have already been explicitly declared as approved in the downstream workload cluster.

TODO:

• Propagate the approval annotation from the APIResourceSchema resources to the generated CRDs
• Add admission to reject APIResouceSchema resources in protected groups without the approval annotation
• Improve APIBinding condition message when the generated CRD is invalid
• Add e2e test

Related issue(s)

Fixes #1083

[sttts]

One comment. Otherwise, looks very good.

[sttts]

Compare 47d0d37 in #1084. Aren't those changes missing?

[astefanutti]

Compare 47d0d37 in #1084. Aren't those changes missing?

Unless I'm mistaken, the changes from 1ed6920 aren't strictly required for the protected API use case. My understanding is that the approved annotation is set at the end of the import execution path, when the NegociatedAPIResource is projected into the published CRD:

kcp/pkg/reconciler/apis/apiresource/negotiation.go

Lines 702 to 707 in 5dd2f2a

	if crdhelpers.IsProtectedCommunityGroup(gvr.Group) {
	if cr.ObjectMeta.Annotations == nil {
	cr.ObjectMeta.Annotations = map[string]string{}
	}
	cr.ObjectMeta.Annotations["api-approved.kubernetes.io"] = "https://github.com/kcp-dev/kubernetes/pull/4"
	}

That being said, it would be required if we were to propagated the set of annotations arbitrarily, then the set would have to be transported along the resources chain (APIResourceImport, NegotiatedAPIResource, ...).

[sttts]

That being said, it would be required if we were to propagated the set of annotations arbitrarily, then the set would have to be transported along the resources chain

But it does not hurt either. Bonus: we don't get this fake pull request number 4, but the real one in case of CRDs on the pcluster side.

[astefanutti]

That being said, it would be required if we were to propagated the set of annotations arbitrarily, then the set would have to be transported along the resources chain

But it does not hurt either. Bonus: we don't get this fake pull request number 4, but the real one in case of CRDs on the pcluster side.

Agreed, that's a good point about that fake approval PR 👍🏼.