Remove all from RabbitmqCluster CRD categories to avoid 'kubectl get all' RBAC noise in cluster-wide installs

[XavierFigari]

Hi,

I’d like to propose an enhancement regarding the RabbitmqCluster CRD categories.

Today the CRD includes the all category (in spec.names.categories, e.g. ["all", "rabbitmq"]), which makes RabbitmqCluster resources show up in kubectl get all.

In a cluster-wide installation (operator installed once for the whole cluster / multiple namespaces), this has an undesirable side-effect in multi-tenant environments:

• Many users routinely run kubectl get all in their namespace to get a quick overview of standard resources (Pods, Services, Deployments, etc.).
• Those users may not be expected to interact with RabbitmqCluster objects, and often do not have RBAC permissions to list/watch this CRD (intentionally).
• As a result, kubectl get all becomes noisy and can return “forbidden” errors for users who otherwise have legitimate access to their namespace resources.

Proposal

Please consider removing all from the CRD categories and keeping only a more specific category such as rabbitmq (so users can still discover it via kubectl get rabbitmq / kubectl get rabbitmqclusters when needed). This is the common approach for many operators, such as MariaDB.

Benefits

• Avoids surprising RBAC errors when running a very common command (kubectl get all)
• Reduces clutter for users who don’t manage RabbitMQ clusters
• Better fits cluster-wide / multi-tenant setups

If you think keeping all is important for some workflows, I’d be happy to discuss alternatives (e.g., documenting why it’s in all, or making it optional in installation manifests if that’s feasible).

Thanks!

[Zerpet]

Hello,

IIRC, we did so for the Topology Operator (removing the all category). I'm in favour of doing the same for this operator. 3rd party operators are not supposed to add to all category.