Feature Overview

• OLM 1.0 needs to allow users which typically do not have CRD listing permissions and might not be aware of which extensions a privileged admin user installed to discover installed extensions if they are offerings services/APIs for them to use in their namespace
• With the discoverability come appropriate permissions for the tenants in the namespace to use serivces/APIs the extension provides
• OLM 1.0 needs to provide distinct controls to privileged admin users in the context of installed operators to define in which namespaces their services/APIs are discoverable and usable by tenants, which is separate from the controls where the operator has permissions to operate (although in practice the set of namespaces where the extensions is discoverable/usable by tenants is going to be a full subset of the set of namespaces the extensions has permissions in (see OCPBU-110)

Goals

• Enable administrators to apply least-privilege principle based on granular control around tenant-level permissions on services/APIs of a particular installed extension
• Allow tenants with limited permissions to discover installed extensions available to them as a single entity that ties together vital metadata (description, documentation, support, feature annotations) and the provided APIs for a great user experience
• Enable tenants to actually use services/APIs provided by an installed extension by automating permission management
• Provide a resource-efficient way to convey the information about extension availability into selected namespaces that works on clusters with potentially thousands/all of the namespaces selected

Requirements

Use Cases

Main use cases:

• An extension gets installed on the cluster and the OLM API used to facilitate this operator offers to specify a list of namespaces in which the extensions should be discoverable, its specified either as a distinct list of existing namespaces or as a label selector query
• Tenants can use OLM APIs to discover the set of extensions available to them in their namespace, either via CLI or UI tools, and can by default expect to have a level of access permissions on their provided services/APIs that corresponds to their own access levels in the namespace, aligned to default role definitions namespace admin/edit/view
• Tenants may discover OLM-managed extensions in their namespace but may not have actual access permissions on their services/APIs because the admin opted out of the default RBAC creation by OLM for the purpose of more manual control about who exactly gets what kind of access
• The set of namespaces in which an extension is discoverable might actually be smaller than the set of namespaces in which the operator has permissions in (see OCPBU-110) to enable it to do meaningful work outside of tenant namespaces, for example using platform / cluster operators in namespaces considered system namespaces

Background, and strategic fit

This is part of a larger effort to re-design vital parts of the OLM APIs and conceptual models to fit the use case of OLM in managed service environments, GitOps-controlled infrastructure and restrictive self-managed deployments in Enterprise environments. You can learn more about it here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing

Assumptions

• Extensions are handled at the cluster level

Documentation Considerations

• Users need to be of how specify the list of namespaces in which an extension ought to be discoverable
• Users need to understand how tenant in those namespace eventually discover the installed extension and its services/APIs
• Users need to be aware of the default RBAC OLM will generate in those namespaces to actually allow the tenants to use the extension and how to disable that beavior
• Users need to understand the difference between discoverability / usability of an extension in a particular set of namespaces and the set of namespaces that the extension itself has permissions in to do meaningful work