Epic Goal

A PoC to showcase end-to-end in how an Operator author can setup Operator RBAC at ease and the Operator can dynamically response to the scoping changes in runtime by the cluster admin as a de-scoped Operator.

Why is this important?

OLM is moving away from namespace-scoped APIs like Subscription, InstallPlan, and ClusterServiceVersion to a different set of cluster-scoped APIs like Operator and Install. The “de-scoped Operators” need adjustments on how to set up RBAC.

De-scoped Operators may still request the cluster- and namespace-scoped permissions they need to run within their installation namespace at install time (i.e. today, via clusterPermissions and permissions). But unlike with scoped operators, the namespace-scoped permissions do not get copied to a predefined set of namespaces and no bindings are created by default.

It’s important that SDK helps Operator authors to understand and achieve those adjustments within their Operator projects following the recommended/best practices to pave the way for the de-scoped Operator world.

Scenarios

• Operators will provide a set of ClusterRoles for the work that they need to do.
  • A de-scoped Operator will not be allowed to install any bindings - this is the job of an administrator.
  • An admin can bind this with a ClusterRoleBinding if they want an Operator to be able to perform its tasks in all namespaces.
  • Or, they may drop a RoleBinding for this role binding the Operator’s ServiceAccount in each desired namespace.

• A convention will be established:
  • a single ClusterRole for a ServiceAccount will be assumed to be required for the Operator to operate.
  • Multiple ClusterRoles will be considered optional (as granular feature-based ClusterRoles), such that creating/deleting them will enable/disable certain aspects of the Operator.
  • One exception:
    • Option a). De-scoped operators are always expected to have read, update /status permission on the APIs they own in all namespaces.
      • This is to ensure that the operator has a communication channel with users (to communicate, for example, that they do not have the proper permission to do work in a particular namespace).
      • OLM will raise alerts when there are CRs in a cluster with no controller capable of updating their status.
    • Option b). It may be saner to simply ensure that an Operator can always create Events
      • That will allow Operators that don't define their own APIs to still communicate with users. It's the model that volume plugins use to communicate as well, so there's precedence in kube.

Acceptance Criteria

• (SDK team working closely with OLM team) Investigate how to support Operator authors to set up Operator's required permissions so cluster admins can easily grant and revoke access in the namespace scoped through RBAC at ease.

• A PoC to showcase how these new scoping mechanisms work end-to-end.

• An upstream step-by-step "how to build an Operator" tutorial style doc to go through these concepts with the PoC to guide users with sample codes and link to the associated sub-projects for accessing codes and more details.

Future Work (not in scope for now):

1. The informer/cache of the Operator/controller can dynamically change the scope in response to the RBAC changes by the cluster admins in runtime without the need for a controller reset.

Open questions:

1. Where does this project repo live? Is it a standalone subproject under the upstream OF repo? Or being a part of the upstream OLM controller ()?

Dependencies (internal and external)

1. Descoping Plan > Transition Plan > RBAC > 1 - Access to do work in a particular namespace
2. Work with OLM to land a recommended way between:
   1. Operators have read, update /status permission on the APIs they own in all namespaces, or
   2. Operators can always create Events

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement No enablement required
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• QE - No QE required
• DOC - No downstream docs required