Epic Goal

• Admins can control which users can use an operator or an operator feature
• Admins can control whether an operator has permission to run or provide a feature

Why is this important?

• The existing RBAC automation in OLM is often cited as a reason why operator authors avoid "AllNamespace" operators - they don't want the operator's roles and rolebindings to be elevated to ClusterRoles and ClusterRoleBindings.  AllNamespace operators are the simplest to treat as "descoped", so if we can solve the rbac automation problem today, we can avoid migration pain in the future.

Scenarios

1. Admins can control which users can use an operator or an operator feature
2. Admins can control whether an operator has permission to run or provide a feature
3. Allow opting out of OLM's default RBAC automation, so that the above controls can be used instead
4. The source scope of this control is either a particular operator or a group of operators
5. The target scope of this control is either an individual user, a user group or a role in a namespace

Examples from SRE-personas:

1. ROSA/OSD customers cannot use APIs for SREP operators unless explicitly granted to the "dedicated-admins" Group
2. ROSA/OSD customers (members of "dedicated-admins" Group) can use APIs for any operator they customer installs without SRE involvement

Out-of-scope / Potential for follow-up

• Authors can define RBAC that a user would need to use an operator or a feature of an operator (including RBAC on sub-resources, e.g. scale)
• Authors can define RBAC that the operator needs to run or provide a feature
• Authors can suggest default permissions for users and default permissions for itself
• If authors didn't specify any specific RBAC users require to use a certain operator features, OLM synthesizes sane default RBAC per CRD that the operator owns
• Streamlining OLM's default RBAC automation around the Subscription API (no create / patch / update verb) so that it easier for non-cluster-admins to discover that they are not allowed to install Operators

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.

Related Work:

1. RBAC Maestro proposal
2. https://github.com/njhale/combo
3. https://github.com/FairwindsOps/rbac-manager

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>