Feature Overview

• Administrative personas can configure which namespaces the extension/Operator can get the requested permissions the extension author deems required for functioning. 

Goals

Address the multi-tenancy issue and security concerns in granting cluster-level permissions in the context of Operators being cluster singletons.

• Admins can review/grant/revoke permissions requested by an Operator to one or multiple (but not all) namespaces in an OLM 1.0-enabled cluster without cluster-wide permissions to avoid security concerns.

• Admins can review/grant/revoke permissions requested by an Operator to all namespaces (at cluster level) in an OLM 1.0-enabled cluster once deemed safe and acceptable.

• Admins can continue to manage multi-tenancy around namespaces on an OLM 1.0-enabled cluster to define which set of cluster tenants get access to an Operator.

• Extensions/Operators can support watching/accessing tenant namespaces following the configuration on the cluster as a cluster-singleton.

• This novel extension permissions management model is widely adopted throughout the Operator ecosystems so customers get benefits from this model to deliver add-ons/extensions to their clusters.  

Requirements

• OLM 1.0 APIs are cluster-scoped to promote the mindset of an being Operator as a singleton cluster extension.  However, this does not always mean "an Operator will get the permissions it needs in all namespaces", nor "all cluster tenants get access to an Operator".
  This feature is critical to fulfill that promise and support our customers as many of them already build multi-tenancy of their clusters around namespaces. 

Use Cases

• OLM 1.0 users can review/grant/revoke permissions requested by an Operator to one or multiple namespaces in a cluster without cluster-wide permissions to avoid security concerns.

• OLM 1.0 users can review/grant/revoke permissions requested by an Operator to all namespaces (at cluster level) in a cluster once deemed safe and acceptable.

• OLM 1.0 users can continue to manage multi-tenancy around namespaces to define which set of cluster tenants get access to an Operator.

• Extension/Operator authors can opt-in to this permissions management model and specify the required permissions for their extensions to work.

• Extension/Operator authors can opt-in to this permissions management model and make their Operators support watching tenant namespaces following the configuration set up by the cluster admins. 

Definition of Done / Acceptance criteria

• All use cases above are implemented and meet the requirements (requirements for MVP take priority).

• Address the multi-tenancy issue and security concerns to the concept of extensions/Operators being cluster singletons and the cluster-scoped OLM 1.0 APIs.

• Pave the way for the smooth transition to OLM 1.0 experience and other more advanced features, e.g.  Canary Style Rollouts, that enable two versions of the extension/controller to co-exist on a cluster and coordinate on which namespaces each "owns" and is responsible for.

Background, and strategic fit

Customers build multi-tenancy of their clusters around namespaces.  Today, the majority of the Operators can be configured as

• either "reconciling events/requests from all namespaces”
• or "only reconciling events/requests from a single namespace”

The former configuration gets the Operator cluster-wide permissions which often raises security concerns, while the latter (per-namespace) Operator configuration increases operational overhead and update problems as the Operator-provided APIs (as CustomResourceDefinitions) are at the scope of a cluster (see extensive operational pain points in here).

As OLM 1.0 is aimed to be the central management of cluster extensions, it needs to promote the mindset of an Operator being an extension as a cluster singleton.  However, this does not always mean "an Operator will get the permissions it needs in all namespaces", nor "all cluster tenants get access to an Operator".  Hence, it is important that:

• Cluster admins can configure the namespaces where an extension/Operator accesses with its requested permissions for functioning.
• Operator authors can support watching/accessing different tenant namespaces according to the configuration on the cluster as a cluster-singleton. 

to pave the way for the smooth transition to the new global singleton Operator model for the OLM 1.0 experience. 

Learn more about this OLM 1.0 feature (F13):

This feature 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.

Learn more about this feature (F13) here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing

Documentation Considerations

• The way "OLM 1.0 supports extension/Operator authors to specify the required permissions for their extensions to work" needs to be documented (in the context of "Developing Operators").

• The way Operator Framework (or with upstream technologies) supports extension/Operator authors to make their Operators watch/access tenant namespaces following the configuration set up by the cluster admins needs to be documented (in the context of "Developing Operators").

• The way "OLM 1.0 supports cluster admins to review/grant/revoke the specified permissions by an Operator to one, or multiple namespaces, or at the cluster level to define which set of cluster tenants get access to an Operator" needs to be documented (in the context of "Administrator tasks").

• Admins need to understand reviewing/granting permissions requested by an Operator to one or multiple namespaces in a cluster without cluster-wide permissions to avoid security concerns.

• Admins need to understand reviewing/granting permissions requested by an Operator to all namespaces (at cluster level) in a cluster only when it is deemed safe and acceptable.

• Users of the extensions/Operators need to understand they will be a part of the driving force to help convince more extension/Operator authors to opt into OLM 1.0's permissions management model that addresses the multi-tenancy issue with API version conflicts and security concerns to cluster-level permissions.