Feature Overview

As RHACM matures and is used for more and more multicluster use cases there is increasing demand for granularity and flexibility in our Role-Based Access Control (RBAC) offering.

Being a modular offering the current growth of RBAC has been an evolving process that we now want to bring into a standardised approach, as much as possible, across all components.

Goals

• Investigate and implement the ways we can offer more fine-grained and usable RBAC within RHACM
• Align, learn from, and centralise the various existing RBAC efforts underway (Search, Virt, GitOps, etc) to ensure a smooth customer experience across all areas wrt RBAC
• Build on the RBAC work done for the OpenShift Virtualization effort
• Allow customers to use RHACM across personas
  • Developers
  • Infra Admins
  • Virt Admins
• Align and lead OCP to cater to more use cases, considering but not limited to:
  • Virt use cases ("Virt Admin")
  • AppDev (GitOps) use cases ("developer")
  • Refined search
  • Tenancy (project) delineation
  • Sovereign clouds (managed service provider (MSP) use cases)
  • Observability
  • Auth?
• Provide flexibility for multicluster single panes of glass
• Align with other product offerings such as RHDH and ROAI (and more) to allow customers to utilise multicluster solutions easily across the OCP "stack
• Provide a relevant and rich UI experience to control RBAC within RHACM
• Document the RBAC structure clearly

Requirements

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

Questions to answer

• So many.
• Do we need to adopt a clearer persona for RHACM and include/exclude certain ones?
• Can other existing Red Hat tools solve some of this already? And if so, how can we make integrations both technically simple and aligned as well as financially acceptable to customers?

Out of Scope

• TBC

Background, and strategic fit

This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?

Assumptions

• Cross-squad
• Multicluster first

Customer Considerations

• Tenancy (projects) are the most common RBAC boundaries requested vs cluster-centric RBAC
• RHACM is not only an Infra tool so we need to consider how to offer a consistent experience across users 

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?