Feature Overview (aka. Goal Summary)  

This feature aims to enhance OLM v1's usability by automating the configuration and management of Role-Based Access Control (RBAC) for API resources exposed by installed operators. 

Currently, cluster admins must manually configure permissions for non-admin users to interact with these Custom Resources (CRs). This feature will provide automated options for granting user access, offering both a legacy mode for broad access and finer-grained control for more precise permission management. 

This directly contributes to F12: Installed extension discovery by ensuring that once an extension is discovered and installed, its provided API resources are appropriately accessible to authorized users, reducing friction in adoption and use.

Goals (aka. expected user outcomes)

Cluster admins:

• Reduce manual effort and complexity in configuring RBAC for operator-provided API resources.
• Choose between different levels of RBAC automation based on their security and operational needs.
• Maintain control over access policies while leveraging OLM's automation.
• Easily grant or revoke access to operator-provided APIs for various users and groups.

Non-admin users:

• Gain access to the API resources they need to interact with, as configured by their admins.
• Experience a consistent and predictable access model for operator-provided functionalities.

Operator authors/providers:

• Ensure their provided APIs are discoverable and usable by target audiences without requiring extensive manual setup from the cluster admins.
• Leverage OLM v1's automated RBAC capabilities to simplify deployment and adoption.

Background

When OLM v0 installs an operator, it automatically adds provided CustomResourceDefinitions (CRDs) to the admin, edit, and view roles across all namespaces.  This broad access, while simplifying initial setup, lacks the granularity many users require, making it impossible to restrict access to specific CRDs or namespaces.  This limitation has been a consistent point of feedback from users (RFEs).

With OLM v1, the management of cluster extensions and their associated CRDs offers significant flexibility.  However, OLM v1 currently does not automatically configure RBAC for users interacting with these new API resources.  By default, only cluster admins have full management access.  Non-admin users typically lack the necessary permissions to create, view, or edit these Custom Resources, requiring cluster admins to manually create and manage ClusterRoles and RoleBindings or ClusterRoleBindings.  While documentation exists to guide these manual steps, the missing automation increases the operational burden and potential for misconfiguration.

The need for finer-grained permissions and automation in OLM v1 is critical to improving the usability of managing operators and enabling broader adoption of OLM v1 as a robust cluster extension management solution. 

This enhanced capability also lays the groundwork for future UI workflows in the OpenShift console for F12: Installed extension discovery.  By ensuring that installed extensions and their API resources are appropriately accessible to authorized users, we can reduce friction in adoption and use, making the entire experience smoother and more intuitive.

Requirements (aka. Acceptance Criteria):

This feature will provide the following options for managing user authorization for API resources.

The core concept is that:

• For any operator's CustomResourceDefinitions (CRDs), appropriate ClusterRoles are made available when OLM v1 is actively managing RBAC (i.e., Mode 1 & 2)
  • Note: These roles can either be provided by the operator's bundle or, if not, automatically generated by OLM v1.  

• Different mechanisms are offered to grant access to these roles

Mode 1: Legacy mode (Automated broad access via aggregation)

This mode replicates the OLM v0 behavior of providing broad access to operator-provided API resources for users with standard Kubernetes roles by leveraging Kubernetes' native ClusterRole aggregation.

• Default ClusterRole creation for each provided API/CRD resource (if not included in the bundle): If an operator's bundle does not explicitly provide ClusterRoles for its APIs/CRDs, OLM v1 automatically generates and creates default ClusterRoles for each provided API resource (CRD).  These generated ClusterRoles follow the OLM v0 naming convention and structure, specifically:
  • for each CRD with kind <KIND> and group <GROUP>:
    • A ClusterRole named <KIND>.<GROUP>-admin will be generated with the * verb on resources: [<KIND>] in apiGroups: [<GROUP>].  This ClusterRole should include the aggregation label rbac.authorization.k8s.io/aggregate-to-admin: "true".
    • A ClusterRole named <KIND>.<GROUP>-edit will be generated with the create, update, patch, delete verbs on resources: [<KIND>] in apiGroups: [<GROUP>].  This ClusterRole should include the aggregation label rbac.authorization.k8s.io/aggregate-to-edit: "true".
    • A ClusterRole named <KIND>.<GROUP>-view will be generated with the get, list, watch verbs on resources: [<KIND>] in apiGroups: [<GROUP>].  This ClusterRole should include the aggregation label rbac.authorization.k8s.io/aggregate-to-view: "true".
    • Additionally, a ClusterRole named <KIND>.<GROUP>-view-crdview will be generated with the get verb on apiextensions.k8s.io customresourcedefinitions for the specific CRD name (<crd-name>).  This ClusterRole should include the aggregation label rbac.authorization.k8s.io/aggregate-to-view: "true".

• • Note: This ensures backward compatibility with the OLM v0 behavior by automatically providing roles that can be later integrated/aggregated with Kubernetes' default user-facing roles.  It also standardizes the generated roles for consistent management, even if the bundle doesn't define them.

• Automatic aggregation to default Kubernetes roles: When this mode is enabled, OLM v1 should ensure that the ClusterRoles for the operator's CustomResources (either generated by OLM v1 or bundle-provided) are configured to aggregate to the default Kubernetes cluster-admin, admin, edit, and view ClusterRoles.
  • This is achieved by ensuring the presence of the standard Kubernetes aggregation labels (rbac.authorization.k8s.io/aggregate-to-admin: "true", rbac.authorization.k8s.io/aggregate-to-edit: "true", rbac.authorization.k8s.io/aggregate-to-view: "true") on the relevant OLM v1-generated (or bundle-provided) ClusterRoles.

• • Note: Unlike OLM v0, OLM v1 will not generate or utilize olm.opgroup.permissions/aggregate-to-<role> labels, as OperatorGroup is not a concept in OLM v1's core RBAC management.

Mode 2: Finer-grained access control (automated binding)

This mode provides more precise control, allowing administrators to directly bind the operator-specific ClusterRoles (generated by OLM v1 or bundle-provided) to specific users or groups, rather than relying solely on aggregation to default roles.

• Default ClusterRole creation for each provided API/CRD resource (if not included in the bundle): If an operator's bundle does not explicitly provide ClusterRoles for its APIs/CRDs, OLM v1 automatically generates and creates default ClusterRoles for each provided API resource (CRD).  These generated ClusterRoles follow the OLM v0 naming convention and structure, specifically:
  • for each CRD with kind <KIND> and group <GROUP>:
    • A ClusterRole named <KIND>.<GROUP>-admin will be generated with the * verb on resources: [<KIND>] in apiGroups: [<GROUP>].  
    • A ClusterRole named <KIND>.<GROUP>-edit will be generated with the create, update, patch, delete verbs on resources: [<KIND>] in apiGroups: [<GROUP>].  
    • A ClusterRole named <KIND>.<GROUP>-view will be generated with the get, list, watch verbs on resources: [<KIND>] in apiGroups: [<GROUP>].  
    • Additionally, a ClusterRole named <KIND>.<GROUP>-view-crdview will be generated with the get verb on apiextensions.k8s.io customresourcedefinitions for the specific CRD name (<crd-name>).  
  • Note: Aggregation labels are not directly used in this mode for binding.  These roles are generated to provide consistent targets for RoleBindings and ClusterRoleBindings.

• Automated ClusterRoleBinding (cluster-wide): Cluster admins can configure OLM v1 to automatically create ClusterRoleBindings that link the operator's ClusterRoles (e.g., <KIND>.<GROUP>-view, <KIND>.<GROUP>-edit, <KIND>.<GROUP>-admin) to specified users, groups, or ServiceAccounts.  This grants permissions across all namespaces for the operator's API resources.

• Automated RoleBinding (namespace-specific): Cluster admins can configure OLM v1 to automatically create RoleBindings that link the operator's ClusterRoles to specified users, groups, or ServiceAccounts within a specified namespace.  This grants permissions only within that designated namespace for the operator's API resources.

• Subject specification: The configuration for automated RoleBinding/ClusterRoleBinding allows specifying subjects by kind (User, Group, ServiceAccount) and name.

Mode 3: Unmanaged mode

This mode reflects the current OLM v1 behavior, where RBAC for operator-provided APIs is left entirely to manual configuration by the cluster admins.

• Default unmanaged state: By default, OLM v1 does NOT automatically configure RBAC for operator-provided API resources unless explicitly configured otherwise by the cluster admins (i.e., unless Mode 1 or Mode 2 is selected).

• Clear indication: OLM v1 should provide a clear indication (e.g., in status conditions or events of the relevant OLM v1 object) that RBAC for an installed operator's API resources is not being automatically managed by OLM, prompting cluster admins to handle manual configuration if needed.

General requirements

• Idempotency: All RBAC configurations managed by OLM v1 should be idempotent, ensuring that repeated application of the configuration results in the same desired state without errors or unintended side effects.

• Conflict resolution: OLM v1 defines a clear strategy for resolving conflicts if an operator's bundle explicitly provides ClusterRoles or RoleBindings that clash with OLM's automated RBAC configurations.  The strategy should be documented and predictable.  (e.g., an updated bundle provides default ClusterRoles for the CRDs that conflict with the existing applied ones in the cluster.  OLM v1 could raise this in the status condition for cluster admins to handle this manually.)

• Rollback capability: Changes made by OLM v1's automated RBAC should be revertible during operator uninstallation or configuration changes, ensuring proper cleanup of created RBAC resources

• Status awareness: Cluster admins should have clear visibility into the RBAC resources (e.g., ClusterRoles, RoleBindings, ClusterRoleBindings) created and managed by OLM v1, whether in the OpenShift console (when supported in the future) or through standard kubectl/oc commands.

 Documentation considerations

• User guide for cluster admins:
  • Comparison of OLM v0's RBAC behavior versus OLM v1's enhanced capabilities.
  • Detailed instructions on how to enable and configure each of the RBAC automation options (i.e., Legacy mode, Finer-grained access control/Automated binding mode, and Unmanaged mode).
  • Clear examples for granting access to individual users and groups using the automated binding options.
  • Detailed explanation of how RoleBindings, ClusterRoleBindings, and aggregation labels interact with OLM v1's RBAC automation.
  • Guidance on how to inspect and verify the RBAC resources created by OLM v1.
  • Best practices for choosing the appropriate RBAC strategy based on security requirements and organizational policies (e.g., how to restrict provided API usage to designated namespaces/users to save billing cost).
  • Troubleshooting guide for common RBAC configuration issues.

• API Reference:
  • Document any new fields or CRD definitions introduced to support RBAC automation (e.g., in ClusterExtention API).