Thanks for raising this! While I agree it would be technically straightforward to support namespaced managed resources, I'm quite wary to do so primarily out of concern about the cognitive and logical burden it would introduce - e.g. both Crossplane users and Crossplane code would need to be able to account for whether a particular managed resource was namespaced or cluster scoped. How would a provider author determine whether their managed resource should be namespaced or cluster scoped?

I'd love to hear more about your use cases for namespaced managed resources. As you point out, Crossplane's approach is to encourage you to abstract your managed resources via an XR and to offer a namespaced claim.

Hey there! One possible user story could go like this:

I am on the infrastructure team at my company and we want to offer Azure (AKS in particular) as a service for engineers via crossplane controller. We want to be able to apply policies, grant permissions, attach quotas and perform cost and audit control.

It seems that logical to achieve this by using namespaces to get k8s native tools to work (RBAC, etc). Does that sound like a legit case?

For our usecase namespaced managed resources would allow us to easily delete all resources created for a deployment. We create a namespace per application. To remove an application we simply delete the namespace and all resources for that application are gone. With non-namespaced crossplane resources we must also label the resources and must know which resources are created by the application.

I am on the infrastructure team at my company and we want to offer Azure (AKS in particular) as a service for engineers via crossplane controller. We want to be able to apply policies, grant permissions, attach quotas and perform cost and audit control.

Crossplane is designed to support this via resource claims (which are namespaced). The idea is that you'd offer AKS as a service via a claim, not via the 'raw' managed resources.

For our usecase namespaced managed resources would allow us to easily delete all resources created for a deployment. We create a namespace per application. To remove an application we simply delete the namespace and all resources for that application are gone. With non-namespaced crossplane resources we must also label the resources and must know which resources are created by the application.

FWIW, I believe this is also something you could do with claims. Deleting a namespace containing Crossplane composite resource claims (XRCs) would cause the claims to be deleted, which in turn would delete the XR and all composed resources.

Generally, I don't think we'll be adding support for namespaced managed resources - at least not without a major version bump. I will leave this issue open to gather more feedback.

Crossplane is designed to support this via resource claims (which are namespaced). The idea is that you'd offer AKS as a service via a claim, not via the 'raw' managed resources.

Got it! Please correct me if I got the idea wrong: if infrastructure owners want to expose all available AWS resources as claims, they need to manually create corresponding claim CRDs. Are there any means to automate this procedure?

Mr @benagricola has created a generator https://github.com/benagricola/crossplane-composition-generator

It's on my to do list to give it a try.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.