Feature Overview

_{This phase focuses on introducing finer controls over permission/access management to APIs provided by operators, while the “discoverability control of the installed extensions/operators” piece of feature F12 will be tackled in the future.}

OLM 1.0 provides more control to administrators to regulate how the services/APIs provided by the installed operators are usable by tenants.

• (which is separate from the controls where the operator has permissions to operate, see F13 in OCPSTRAT-393).

Goals

• Administrators can choose between “legacy OLM v0 mode (do what OLM v0 does)”, “managed (full control)”, and “unmanaged (do nothing)” over permissions to the APIs provided by an operator API.

• Enable Administrators to apply the least-privilege principle with the “managed (full control)” option allowing fine-grained permissions configuration, letting administrators specify namespaces, users, groups, APIs, and specific permissions for each.

• Whenever administrators modify an operator’s permissions configuration, OLM 1.0 constantly keeps the system up to date.

• Enable tenants to use services/APIs provided by an installed extension by OLM 1.0’s automating permission management.

Requirements

Background, and strategic fit

When you install an operator with OLM v0, OLM adds the operator’s provided APIs to the admin/edit/view roles for all namespaces.  This means that any user with admin, edit, or view permission in any namespace has access to the operator’s APIs, and there is no way to change this.  Users have asked for a finer-grained permissions configuration for operator APIs.

Users who may not have the permissions to install operators are interested in learning which operators are available for them to use in a cluster. While a user may be able to see various operator-provided APIs are present in the cluster, they may not have permission to use all of them. Trying to use an API and getting a “permission denied” error may not be the best user experience. A better option is to provide a means for the user to ask “what operators can I use?”

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

Relevant upstream CNCF OLM engineering brief(s):

• Brief​: Access Management of provided APIs  

Documentation Considerations

• Admin-type users need to understand the differences between the permissions management modes.

• Admin-type users need to fully understand how all the options for the managed permissions mode work.

• Users need to understand they can only use OLM to grant permissions to APIs provided by the operator being installed. If they need to grant permissions to APIs provided by a dependency, they need to create a separate configuration for the dependency as its own operator.