Description / background info
At the December 2024 Virtualization vF2F, RBAC was one of the main topics discussed on Day 2. 

The challenges around RBAC and intuitive permissions in the UI across OCP, CNV and ACM were a key topic of discussion. The group of stakeholders identified the need to address both single and multicluster scenarios, with a focus on improving the consistency, granularity, and usability of permissions management. 

The following problem areas were emphasized with corresponding potential 'how might we's' to attempt to address these issues:

• Lack of fine-grained access control: 
  • Inventing new new or resuse
    • Determine if we will split the roles or define new ones
    • Consider FabricInventory and ClusterPermissions
    • Determine if additional tooling is possible to manage RBAC relationships across OpenShift, Ansible and RHEL
  • Understand roles
    • Understand common virtualization roles and pre-define them in OCP  
  • Uncategorized
    • Align with OBS-style metrics
    • RBAC reference architecture

• More intuitive permissions in the UI
  • Predefined roles
    • Provide out-of-the-box roles with clear descriptions and permissions
    • Optional: Consider how customers migrate existing RBAC roles from VMware to RH  
  • Simplified bindings
    • Have folders to be a RoleBinding builder tool for objects at different levels - cluster, namespace, object level
    • Build an easy to use UI to define roles, assign user to roles and bind them to projects / folders
    • Downplay the 'rolebinding' concept and let users think in role and user/group terms (this is what clusterPermissions in ACM does)
    • GUI to define a new role: map user(groups) to (clustergroup, namespacegroup, resource) and tasks that are permitted  
  • Clarity of roles
    • Role definitions that describe the ideal persona. eg "This Role is for Security Ops which need to view all resources and take actions at the cluster scope". and then a clear list of controls/permissions which this permits  
  • Displaying permissions
    • Show the relationships between users/groups, roles and resources (VM's in VMWare show inherited permissions  
• Lack of RBAC consistency across clusters and inability to manage global RBAC  
  • SSO
    • Reconcile RBAC and SSO across fleet (unless a cluster opts out)  
    • Enable SSO on all clusters, ensure to have a consistent IDP for all. In ACM build RoleBindings using Folders, and push them to spoke clusters
  • Push RBAC to multicluster level 
    • Must define RBAC roles at the ACM level, then ACM configures it at the managed cluster level  
    • We might need to start with a common IDP approach across the managed clusters as a starting point. The Hub could be responsible for coordinating the IDP configuration for managed clusters. 
  • RBAC across RH portfolio
    • Red Hat honestly needs a consistent authN authZ solution that provides global RBAC across its portfolio. As it is, customers will have to navigate console.rh, individual product implementations and all of them are different. Consider competitors that have strong definitions and years of investment in production ready RBAC capabilities.  

Goals for the work

• Establish a unified and intuitive RBAC experience for both single and multicluster environments

• Ensure the UI for permissions management is user-friendly, scalable, and aligned with common virtualization roles and customer use cases

• Enabling customers to manage permissions effectively at scale

Customer input

"At UPS, they’re starting to do self-service with the vRealize or Aria, and now they want to do it through ACM. But it has to… provide that RBAC, ideally on a per object level, but generally they apply that at the folder level in vCenter.” 

• Source: Principal Consulting Architect

“I think being able to split out the permissions in RBAC and being able to simply say something like, ‘Hey, I want this person to be able to see the logs and that's all they get,’ that would essentially eliminate a lot of the issues that we have... that would be a generic benefit from not just OpenShift Virt or OpenShift, but across the entire environment.”

• Source: Solution Architect

“When we actually went through the permissions UI (in ACS), the way that’s set up is really efficient and really easy to understand with the groups and access lists and scope. I think if Red Hat implemented that in terms of OpenShift in general, that would actually end up fixing all of those issues.” 

• Source: Principal Consulting Architect

"The equivalent in our case would be, well I guess we’re adding this folder thing that’s based on like labels or annotations, but that level or on a project level in OpenShift, which would be a project in the spoke cluster, not in the hub cluster.”

• Source: Principal Consulting Architect

Tracking success

We will track the success of these initiatives through determining the appropriate analytics, identifying key metrics, and prioritizing continuous customer feedback through surveys and usability testing.

Definition of done - Targeted for [estimate a timeframe once known/In Progress]

• Stakeholders have approved solutions for fine-grained access control, intuitive permissions, and global RBAC consistency

Design artifacts

TBD