Feature Overview

Provide an easy-to-use, authorization solution for multicluster fleet operations through a declarative security schema that models organizational relationships and resource hierarch whilst enabling highly granular policy enforcement at the object(resource) level (ie individual Pods or Custom Resources).

Because RHACM managed clusters may be (m)any K8s variant(s) it should layer directly over native Kubernetes RBAC so that users can manage complex, nested access rules while guaranteeing full compatibility with all core K8s functionality that might be found on our managed clusters from any Kubernetes distributions.

The solution has the same availability as ACM. 

Extensive documentation exists to ensure customers understand how to use, secure and manage the system.

There is a UI component to enable the User Experience. We want to appeal to both CLI users and GUI users to ensure Fleet management security is easy for multiple personas.

The solution is not the same as the existing RBAC solution for virtualization but will take into account the actions there and mitigate user migration from that system to this (whatever both may be).

Goals

• Allow for fine-grained RBAC much deeper than the existing "per cluster" model we have now.
• Investigate ReBAC as per industry direction for fleet managed (example: Google Zanzibar) 
• It should be compatible and/or allow easy migration from existing efforts in place for Virtualization so customers don't need to do anything to gain it.
• Provide the same solution regardless of infrastructure ensuring operators are able easily set up the solution on-premises and on cloud and can use it with any K8s-compliant managed cluster.
• Don't build it from scratch. Look into the leading community ReBAC solutions and build on them and their community
• Make sure integration between ReBAC and Kubernetes is in place
  • Authorization data must be kept up-to-date.
  • Applications and APIs have an easy way to query that data.
  • System is deployed and managed natively within Kubernetes.
• The system is fully auditable even when a hub is down and/or in an active/passive failover situation
• The system is compatible with the existing DR solution of active/passive (ie it must be accounted for and QE'd for in DR testing)
• The solution should have the same availability as ACM for Hub RBAC
• The solution should have the same availability as the spoke clusters, regardless of the status of the hub

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.

Use Cases

This Section:

• As a RHACM admin I can assign a core set of RBAC to all my users for basic Observability, Console, and Search access.
• As a RHACM administrator I am able to assign a set of pre-defined role groupings that will provide recommended best practices (opinionated) RBAC settings for key areas:
• As a developer, I want clear, predefined permissions for my team's specific projects and namespaces, so that I always know what actions I can perform and avoid access denied errors, reducing frustration and wasted time.
• As a Sovereign Cloud Administrator, I want to provide my customers with tailored, secure access to only the RHACM features relevant to their tenancy, so that they can efficiently manage their own deployments without compromising the integrity or security of the broader cloud infrastructure.
• As a developer I want a "developer view" in RHACM allowing me to manage my Argo deployments within RHACM and see and manage reconciliation state, as well as view metrics for my deployments.
• As an RHACM administrator I would like to cater to Developers, Data Scientists, MSPs, and Infrastructure Administrators by being able to restrict individual elements of RHACM from cluster to specific namespaces, API groups, resource types, and even individual verbs or custom resources.
• As an RHACM user I expect search results to only return information relevant to my security profile.
• As an RHACM user I expect to find observability metrics and graphs to only return information relevant to my security profile.
• As an RHACM user I expect the UI to only display elements and details relevant to my security profile.
• As a RHACM developer I have a clear set of instructions on how to build components within the security guidelines.
• As an Add-on developer I have a clear set of instructions and information about how to accommodate the required security guidelines.
• [Spoke]As a RHACM user I need a UX that allows me to build roles easily and assign them simply; having a UI allows me to avoid mistakes in syntax that could lead to security issues.
• As an RHACM user I expect observability data to be restricted to the views I want. It should follow the same tenancy boundaries as I’m restricted to.
• As an RHACM admin I expect my tenants observability data to be constrained to a restricted view so they cannot see other tenants observability data.
• As a tenant on a cluster I should only see resources that belong to me across ALL of ACM, including observability, cost management, governance, pods, and UI elements.
• As a user I don’t see any UI menus for anything but things I can interact with. This means menu will need to be hidden based on RBAC otherwise I will get “access denied” errors.

Questions to answer

• How does this work with other multicluster efforts such as
  • CNV
  • Multicluster SDK
  • UX
• Is it possible to offer roles using the new ReBAC models that align to persona (A virt user, a virt admins, app admins, etc). This would allow customers to use the new RBAC with a lower barrier to entry (ie we offer pre-written models they can use and then build on)
• What role does https://github.com/stolostron/multicluster-role-assignment play in the solution? Would we use this for lower level access and Kube role management leaving the ReBAC (SpiceDB, Kessel) for finer grained user auth, etc)?

Out of Scope

• …

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

• ...

Customer Considerations

• ...

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)?