Restricting visibility of specific CRDs to some namespaces

[lulf]

We have our operator working nicely on OCP 4. Our operator(EnMasse, AMQ Online) is a "global" operator, but not all of the CRDs makes sense to expose to all namespaces. This makes the console view a bit confusing because you can create resources that are not being acted on by the operator.

Is it possible, or will it be possible, to put restrictions in which namespaces CRDs can be created and/or be visible? For instance, we have 4 CRDs that only makes sense to create in the operator namespace, and 3 api-service backed resources that should be possible to create across the entire cluster.

[njhale]

@lulf

Is it possible, or will it be possible, to put restrictions in which namespaces CRDs can be created and/or be visible?

From OLMs perspective, the roles to create, edit, and view CRs for a provided API (a resource provided by a CRD or APIService) are generated implicitly as ClusterRoles which are aggregated to kube's default admin, edit, and view ClusteRoles. This means that CRUD capabilities on CRs are not tied to its OperatorGroup's namespace selection, but are instead available to any user with a RoleBinding to kube's default admin, edit, or view ClusterRoles. A view ClusterRole is also generated for the CRD which is also aggregated to the default view ClusterRole (see our docs for more details on OperatorGroup RBAC). Although we generate a view ClusterRole for the CRD, we can't actually prevent users from viewing CRDs because they are surfaced in kube's discovery regardless of any RBAC.

Currently, OLM will generate copied CSV's in the target namespaces of an OperatorGroup for each operator in its operator namespace. This is how OLM provides information about what operators, and consequently, CRs are "available" in a target namespace.

For instance, we have 4 CRDs that only makes sense to create in the operator namespace, and 3 api-service backed resources that should be possible to create across the entire cluster.

Could you explain the use case for those 4 CRDs in more detail? It will help us determine if we are missing a valid mode of operator deployment, or if we can fit your operator into our current model in some other way.

[lulf]

Could you explain the use case for those 4 CRDs in more detail? It will help us determine if we are missing a valid mode of operator deployment, or if we can fit your operator into our current model in some other way.

Our operator is a global operator, i.e. we support only 1 of it across the cluster. The model is that a service admin is responsible for installing and managing this operator on the cluster. Which namespace the operator is installed to does not matter, but we have the following in the CSV:

  installModes:
  - type: OwnNamespace
    supported: true
  - type: SingleNamespace
    supported: true
  - type: MultiNamespace
    supported: false
  - type: AllNamespaces
    supported: true

We then have 4 CRDs which are only relevant to the service admin: AddressPlan, AddressSpacePlan, StandardInfraConfig and BrokeredInfraConfig

The service admin is responsible for creating instances of those CRs, which affect the operator behavior.

---

Then there is the developer, who is using the 3 api-service backed resources: AddressSpace, Address and MessagingUser. This user does not have access to the namespace where the operator is running, but is creating these 3 resources in order to 'self-service' without caring about what the underlying operator is doing (which is is managed and visiable only by the service-admin).

My concern then, is that in the UI, the CRDs that the service admin (or anyone with sufficient privileges) is using to manage the service, are also visible to the developer. From the developer POV, this is confusing, because those resources makes no sense for the developer to create.

---

So for the CLI, I understand that standard RBAC rules will allow the developer to create these resources. However, it would be nice if we could give a hint in the CSV as to which namespaces the resource should be visiblej in the UI, or alternatively give a hint on how to restrict the RBAC rules for creating/viewing the resource to a specific namespace (i.e. namespaceVisibility: installed | all)

---

Here is our CSV for reference: https://github.com/EnMasseProject/enmasse/blob/master/templates/csv/enmasse.clusterserviceversion.yaml

[lulf]

@njhale

Perhaps an even simpler explanation of their use is that the CRDs are used for configuring the operator itself, i.e their creation is not causing the operator to take action and create other resources.

The instances of these CRDs are reade when the other 3 api-service backed resources are created. So you can think of them as similar to ConfigMaps that the operator uses to configure itself, but with schema validation, custom syntax etc.

[njhale]

@lulf Sorry it took so long for me to get back. I think that both of your explanations are super clear and describe a totally legitimate mode of operation for an operator. We don't currently have a way to restrict access to subsets of CRs that a CSV provides. @alecmerdler may have some insight about how we might alter the UI to support hiding, but I think there should be a feature in OLM that supports your use-case.

I'm going to confer with the rest of the team about adding this as a story to our board. I will keep you posted with updates.

[stale]

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.

[njhale]

Closing in favor of #975 as I think it more concisely describes the requested feature. Feel free to reopen this if there's some distinction I missed.